Dynamic (also known as parameterized) components are fields in the S-Docs template builder that dynamically pull in data directly from Salesforce. Dynamic components save valuable time on manual document generation and data entry, enabling you to generate a personalized document in seconds. Learn how dynamic components work in S-Docs for Salesforce here.
Why and when should you use dynamic components?
Instead of using conditional logic and creating a superset of all of the different types of conditions that could ever be needed, a dynamic component allows you to make the reference to the component template itself dynamic.
Dynamic components depend on what is variable in the component, for instance, the country someone lives in, the type of product being purchased, and beyond.
For example, instead of typing out all of the different possible languages you may need in a template (as listed in the top half of the code below), you can use a dynamic merge field inside of your component reference (as listed in the code as {{{{!Proposal Pricing Sheet {{Opportunity.language}} Component}}}}). Then, the language of the opportunity will automatically be used depending on what is in Salesforce.
This makes for a much cleaner, easier-to-manage template when you want to dynamically merge Salesforce data into your document.
<!--RENDER='{{!BaseObject.ID}}'== null -->{{!BaseObject.Field}} <!--ENDRENDER-->
{{Opportunity.lp_language_c}} == 'English' -->
{{{{!Proposal Pricing Sheet English Component}}}}
<!--ENDRENDER-->
<!--RENDER={{!Opportunity.lp_language_c}} == 'Spanish' -->
{{{{!Proposal Pricing Sheet {{!Opportunity.language}} Component}}}}
<!--ENDRENDER-->
When should you not use dynamic components?
Dynamic components are only ideal for certain uses. If you need to use more than three variable elements of the component name, dynamic components become complicated and keeping the naming convention organized can be difficult.
Instead, use a query to fetch component. There a few benefits to this approach:
- More scalable. Query to fetch components are contingent on the fields in the S-Docs template in Salesforce, whereas, in a dynamic component, they are contingent on the naming convention. Because of this, query to fetch components are ideal if you need to use more than three variable elements.
- Simple naming convention. Benefits of using query to fetch components are that the naming convention remains easy and flexible — there’s no need to standardize.
- Variable information is stored in fields. Instead of using a component’s name to store the variable info, the variable information can be stored in fields on the template record. This means that, through creating and using fully extensible custom fields, out of the box can be leveraged for some cases.
The below code is an example of a query to fetch component in an S-Docs template. Here, you can see we are using the Line of Business and Language fields on the base Opportunity record to dynamically form a query to grab the S-Doc template that matches the Line of Business and Language within the record.
<!--{{!
<lineitemsSOQL>
<class>none</class>
<queryname>myQuery1</queryname>
<soql>SELECT Name
FROM SDOC_SDTEMPLATE_C
WHERE LOB__c ='{{!Opportunity.LOB}}'
AND Language = '{{!Opportunity.Language}}'</soql>
</lineitemsSOQL>
}}-->
{{{{{{!myQuery1.name}}}}}}
Some downsides include that you need to use custom fields to create, track, and maintain on Template objects.
Additional considerations
- In S-Sign, one common application of dynamic components is to drive which types of signature events you will need to account for. Here are some examples:
- If a patient is below 18, you will need to require a parent/guardian signature
- If an occupant of a home is the owner, include one signature. If they’re a renter, include two: one for the tenant and one for the landlord.
Other possible major considerations include:
- S-Sign Inputs. These inputs can be used within component templates, but remember that the S-Sign Field is defined within the Parent Template and used within the Component — it’s not defined within the component. Ensure all of the S-Sign Fields defined are used somewhere within the output document and ensure that no undefined fields are used
- Runtime prompts. These prompts are also compatible with dynamic component references. This allows the user to supply parameters that populate the component name or component query. All of the concepts and paradigms are the same as those discussed in this article, but they allow user input to drive the process rather than Salesforce data.
- Repeating components. Component templates can also be repeated “N” number of times, once for each item in a series of records. Imagine the following: Instead of a basic quote, your organization wants to differentiate your offerings by including an entire Product Specification Sheet for each Product connected to an Opportunity. The Spec Sheet should include dynamic data, images, and more info about each product. The Spec Sheet might be included once if only one product is purchased, 10 times for 10 products, etc. This is where the concept of Repeating Components becomes useful.
- Avoid nested components. You can try them at your own risk, but we advise against using nested components because the number of executed SOQL queries can exponentially increase, resulting in encountering Salesforce governing limits.