cancel
Showing results for 
Search instead for 
Did you mean: 

Output Document SFM - Add Page Break & Preview Options

Output Document SFM - Add Page Break & Preview Options

Output Document SFM - Add Page Break & Preview Options

Additionally there is no Preview option to see how the PDF will be rendered, which leads to improperly formatted output documents (customer facing).  The PDF rendered is significantly different from the output SFM display, which forces users to trial-and-error, with finalization for each iteration, until they get the proper output.  This is very wasteful.

If proper preview is achieved, then user-defined formatting should be possible.  The most important such control would be on user-defined page break to allow desired formatting across pages (to avoid incoherent overflows).

Request:

1)  Adjust output SFM display to mirror PDF render

2)  If 1 not possible, Add optional Preview function to be added as button to Output Document SFM

3)  Add optional Page Break function to output document SFM transaction designer

What is the underlying problem do you intend to solve with this idea?
No user defined pagination or preview possible
How is the problem being addressed today, if at all?
No workaround.
Product Area?
Mobile Field Service Management Parts Management Work Order Management
What version of ServiceMax are you on?
Summer 16
8 Comments
Sushi Chef
Sushi Chef

You can modify the styling i.e. .workorder-details table tr {page-break-inside:avoid; page-break-after:auto}

Roast Chef
Roast Chef

Thanks Scott for the feedback.  I think my idea was not well worded as inner breaks on tables is not the real issue faced.  We have a lot of internal formatting defined, but the problem is twofold even with these markups:

  1. Output SFM display page is not representative of how the PDF rendering actually takes place.  So the user has no ability, outside of Finalize, to know whether or not the formatting is correct prior to generation of output.  This is leading to a lot of trial and error in making small adjustments, finalizing, going back and re-adjusting, finalizing, etc. which is very wasteful.
  2. Page break and other edits from within Output SFM.  Once output SFM display is representative of the actual PDF rendering, the user would need more control over formatting edits, such as insertion of user defined page break.  The difficulty of course is that the merge fields shouldn't be editable from here as that would override the controls within the SFM from which they were created.  But formatting items could be editable with no ill effect.
Sushi Chef
Sushi Chef

I think I follow. Is this primarily due to the number of records on the output document or is it due to text fields that can vary in line count?

Roast Chef
Roast Chef

It can be either.  The number of table rows varies wildly depending on the Work Order, as do the Text area sections.  The trouble becomes that the Output Doc SFM display has very little relation to what the PDF rendering will output, so the user has to go back and forth adding/removing lines (almost always in Text area sections) to adjust how the document will display on customer PDF.

Sushi Chef
Sushi Chef

I would find the 3 most common factors that prevail a page break is required. it could be a combination of record counts or char length in a text field. then use boolean formulas that return a true wshen those factors are present. then  {{$F.IF($F.FORMAT('{0}',$D.Work_Order.Customer_Boolean__c) == 'true', '<br />', ''))}}

Sushi Chef
Sushi Chef

Syntax may be slightly off, currently away from my favored machine.

Roast Chef
Roast Chef

In our case the different combinations that would drive an undesirable page break are nearly infinite because of the contribution of table rows, and multiple independent long text fields.  We're employing styles to avoid breaks in certain places, but what ends up happening is text fields especially getting broke in confusing places (or in ways that look poor on the eventual PDF output).  This cannot be seen until PDF rendered, and then user has to go back, edit the original fields, go back to SFM and output PDF again to see if it looks good.  First priority would really be for the SFM Output Doc display to mimic how the PDF output would take place (or at least allow preview that doesn't create/save the attachment), and then to allow ad-hoc formatting tools for the user within the SFM.  If there is any significant amount of data currently it's a completely trial and error scenario for the individual users unfortunately.  If I'm misunderstanding your suggestion please let me know, and thanks as always for taking a look!

Product Team
Product Team

Via Joseph JuneFSA (iPad) 3.2.0 will have the ability to print preview the document before it is converted into a PDF file. Because the PDF rendering will be done via the Salesforce PDF render, it is not possible to get the exact preview of the document. FSA Phone apps will generate the PDF file within the mobile app so the user will have the ability to preview the exact output.