Support for Nested Child Level Merge Fields (Pre-FX2)

X-Author and Merge Server can support resolving merge fields for nested child-level items at the child and grandchild levels of an agreement or proposal.

With X-Author you can insert merge fields for child relationship objects that have a master/detail child relationship with the agreement and merge fields for a third level, the grandchild level objects with a lookup relationship to the original object that is a child object of the agreement.

X-Author supports either master/detail or lookup relationships at the child level, as well as lookup relationships from a grandchild that is related to the original agreement by its relationship to the child agreement. Only lookups at the grandchild or third level are possible.

X-Author supports inserting qualified merge fields for objects at both the child and grandchild levels. To summarize, X-Author has:

The ability to pick standard merge fields for object child and grandchild levels
The ability to pick lookup (qualified) merge fields for object child and grandchild levels
The ability to distinguish between lookups at parent, child, and grandchild levels
The ability to insert section tags to denote nested child/grandchild levels
The ability to insert lookup fields in tables and sections
The ability to insert conditions in tables and sections
Backward compatibility with pre-existing templates

What this means is you can have Related Lists for Service Plan level information for an agreement, and then easily insert merge fields for this information into your templates. You can then define another object, say Service Plan Devices, which is related to a Service Plan by a lookup relationship, and then define merge fields for the agreement service plan devices that can be repeated for each agreement service plan.

The mechanism to support the features described above involves adding section tags to support defining an area to the merge server so it can interpret line item merge fields within a section as being grandchildren of the object whose scope enclosed the original section tags.

As before, qualified merge fields have the following object field syntax to qualify the lookup fields:

{ QMERGEFIELD apttus__account__c.account_accountnumber \* MERGEFORMAT }

Section Tags

X-Author contains the ability to define a section, using start and end tags to denote where the section begins and ends, respectively. Within a section, there can be nested line items as well. Normal agreement level2 (master/child relationship to agreement) items can be defined inside a table, but can also be defined as a section as follows:

{ objectname_section_start }…{ objectname_section_end }

Template designers who want to create templates that display nested child line items (down a max of two levels from the agreement level object or three levels overall), will use the section feature of Author to define the outer level child item.

To demonstrate this feature, we show an example of creating a template for an agreement object that has two nested level of child relationships, including agreement service plan line item details (level 2) and agreement service plan devices (level 3). In this example, an agreement can have one or more agreement service plans (level2), and an agreement service plan can in turn have one or more agreement service plan devices (level3).

The following screen shows how the Insert Merge Fields dialog of the Author looks to select agreement (Level 1) mergefields:

The merge fields that are inserted look like the following:

{ MERGEFIELD apts_agreement_name \* MERGEFORMAT }{ MERGEFIELD apts_agreement_ff_agreement_number \* MERGEFORMAT }

As before, we can also insert level 1 lookup fields for agreement level fields, such as the requestor user’s email address, which results in the following QMERGEFIELD getting inserted:

{ QMERGEFIELD apttus__requestor__c.user_email \* MERGEFORMAT }

For level 1 items, check boxes Insert fields in section and Insert fields in table are disabled. The insertion above corresponds to the following data source:

Agreement (Level 1)

Agreement Name
Agreement Number
Agreement requestor - User (level1 lookup)
- Email

Agreement children with master-detail or lookup relationships back to the agreement object (such as agreement service plans, agreement clauses, etc) can be added as before by selecting the child relationship object in the left-side pane and the desired fields in the right-side pane.

The selection above gives the user the ability to specify merge fields at Level 2 inside a section:

Agreement Service Plan (Child of agreement) (Level 2)

Service plan name
Service plan family
Service plan type

The merge fields that get inserted look like this:

{ MERGEFIELD agreement_service_plan_section_start }

{ MERGEFIELD agreement_service_plan_name \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_family \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_type \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_section_end }

If you need to insert lookup fields to resolve within this master detail relationship you can place a cursor within section tags, invoke Insert Merge Fields dialog and expand the right-side pane to select lookup fields by checking the Insert lookup field check box.

The selection above gives the user the ability to specify lookup fields at Level 2 and corresponds to the following data source:

Agreement (Level 1)

Agreement Name
Agreement Number
Agreement requestor - User (level1 lookup)
- Email

Agreement Service Plan (Child of agreement) (Level 2)

Service plan name
Service plan family
Service plan type
Service contact - Contact (level2 lookup)
- Email

The Level 2 qualified merge field that is inserted within section tags looks like the following:

{ QMERGEFIELD service_contact__c.contact_email \* MERGEFORMAT }

You can also insert the level1 lookup field for the agreement inside the section tags. So if we insert this Level 2 qualified merge field for the Service contact email address and another – Level 1 qualified merge field for the Agreement requestor email address - inside the section (with the insertion point and selection inside the section start and end tags), it will look like as follows:

{ MERGEFIELD agreement_service_plan_section_start }

{ MERGEFIELD agreement_service_plan_name \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_family \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_type \* MERGEFORMAT }

{ QMERGEFIELD service_contact__c.contact_email \* MERGEFORMAT }

{ QMERGEFIELD apttus__requestor__c.user_email \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_section_end }

If you want to insert merge fields from a deeper level, such as Level 3 described above (for agreement service plan devices), you simply select Agreement Service Plan Devices from the left-side pane as the object and the desired fields in the right-side pane. Since you will be inserting these grandchild objects placing a cursor inside the section, they will be inserted in a table; notice that the check box Insert fields in table has become checked and grayed out automatically:

The selection above gives the user the ability to specify merge fields at Level 3 and corresponds to the following structure:

Agreement (Level 1)

Agreement Name
Agreement Number
Agreement requestor - User (level1 lookup)
- Email

Agreement Service Plan (Child of agreement) (Level 2)_2

Service plan name
Service plan family
Service plan type
Service contact - Contact (level2 lookup)
- Email

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Service plan device
Service plan device cost
Service plan device status
Service plan device list price

Once these merge fields are added, the part of the template document with section tags should look like the following:

{ MERGEFIELD agreement_service_plan_section_start }

{ MERGEFIELD agreement_service_plan_name \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_family \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_type \* MERGEFORMAT }

{ QMERGEFIELD service_contact__c.contact_email \* MERGEFORMAT }

{ QMERGEFIELD apttus__requestor__c.user_email \* MERGEFORMAT }


Device	Device Cost	Device Status	List Price
`_{{ MERGEFIELD Service_Plan_Device_start }{ MERGEFIELD service_plan_device_device \* MERGEFORMAT }}`	`_{{ MERGEFIELD service_plan_device _device_cost \* MERGEFORMAT }}`	`_{{ MERGEFIELD service_plan_device _device_status \* MERGEFORMAT }}`	`_{{ MERGEFIELD service_plan_device _list_price \* MERGEFORMAT }{ MERGEFIELD Service_Plan _Device_end }}`

{ MERGEFIELD agreement_service_plan_section_end }

With Level 1 and Level 2 lookup fields, you can also insert Level 3 object lookup fields. Place a cursor within section tags, invoke Insert Merge Fields dialog, check the Insert lookup field check box to select several Level 3 lookup fields for the agreement service plan device line items:

The selection above gives the user the ability to specify lookup fields at Level 3:

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Device – ODevice (level3 lookup)
ODevice description
ODevice type
OD manufacturer

The inserted merge fields look like the following:


ODevice Description	ODevice Type	ODevice Manufacturer
`_{{ MERGEFIELD Service_Plan_Device_start }{ QMERGEFIELD device__c.o_device _odevice_description \* MERGEFORMAT }}`	`_{{ QMERGEFIELD device__c.o_devic e_odevice_type \* MERGEFORMAT }}`	`_{{ QMERGEFIELD device__c.o_device_od_manufacturer \* MERGEFORMAT }{ MERGEFIELD Service_Plan_Device_end }}`

As with Level 1 and Level 2 objects, we can also insert Level 1 and Level 2 lookup fields inside of the line item table for a Level 3 object; although it doesn’t really make sense to always do this since these values will get repeated for every Level 3 field that is retrieved. Identify the place inside the table to insert these qualified merge field, place the cursor, invoke Insert Merge Fields dialog and proceed with the insertion of the merge fields:

Service contact - Contact (level2 lookup)
- Email
Agreement requestor - User (level1 lookup)
- Email

Here is how the table for Level 3 object with all merge fields and qualified merge fields might look like:


Device	Service Contact Email address level2 qualified merge field	Agr. Requestor Email Address level1 qualified merge field	ODevice Description level3 qualified merge fields	ODevice Type level3 qualified merge fields	OD Manufacturer level3 qualified merge fields	Device Cost	Device Status	List Price
`_{{ MERGE FIELD Service_ Plan_Device _start }{ MERGE FIELD service_ plan_ device_device \* MERGE FORMAT }}`	`_{{ QMERGE FIELD service _contact __c.contact _email \* MERGE FORMAT }}`	`_{{ QMERGE FIELD apttus__ requestor __c.user _email \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _odevice _description \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _odevice _type \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _od _manufacturer \* MERGE FORMAT }}`	`_{{ MERGE FIELD service _plan_device _device_cost \* MERGE FORMAT }}`	`_{{ MERGE FIELD service_plan _device_ device _status \* MERGE FORMAT }}`	`_{{ MERGE FIELD service_plan _device_list _price \* MERGE FORMAT }{ MERGE FIELD Service _Plan_ Device_end }}`

Combining all of these steps together, we can now show the complete structure including Levels 1 through 3:

Agreement (Level 1)

Agreement Name
Agreement Number
Agreement requestor - User (level1 lookup)
- Email

Agreement Service Plan (Child of agreement) (Level 2)

Service plan name
Service plan family
Service plan type
Service contact – Contact (level2 lookup)
- Email
Agreement requestor - User (level1 lookup)
- Email

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Service plan device
Service plan device cost
Service plan device status
Service plan device list price
Device – ODevice (level3 lookup)
ODevice description
ODevice type
OD manufacturer
- Service contact – Contact (level2 lookup)
- Email
Agreement requestor - User (level1 lookup)
- Email

The template with all inserted merge fields might look like the below example (the comments in italic describe the types of merge fields and qualified merge fields that are inserted inside sections and tables for the objects of level1 through level3):

{ MERGEFIELD apts_agreement_name \* MERGEFORMAT }{ MERGEFIELD apts_agreement_ff_agreement_number \* MERGEFORMAT }

level1 qualified merge fields outside section:

{ QMERGEFIELD apttus__requestor__c.user_email \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_section_start }

level2 merge fields inside section:

{ MERGEFIELD agreement_service_plan_name \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_family \* MERGEFORMAT }

{ MERGEFIELD agreement_service_plan_service_plan_type \* MERGEFORMAT }

level2 qualified merge fields inside section:

{ QMERGEFIELD service_contact__c.contact_email \* MERGEFORMAT }

level1 qualified merge fields inside section:

{ QMERGEFIELD apttus__requestor__c.user_email \* MERGEFORMAT }

level3 merge fields within line item tags inside section:


Device	Service Contact Email address level2 qualified merge field	Agr. Requestor Email Address level1 qualified merge field	ODevice Description level3 qualified merge fields	ODevice Type level3 qualified merge fields	OD Manufacturer level3 qualified merge fields	Device Cost	Device Status	List Price
`_{{ MERGE FIELD Service_ Plan_Device _start }{ MERGE FIELD service_ plan_ device_device \* MERGE FORMAT }}`	`_{{ QMERGE FIELD service _contact __c.contact _email \* MERGE FORMAT }}`	`_{{ QMERGE FIELD apttus__ requestor __c.user _email \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _odevice _description \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _odevice _type \* MERGE FORMAT }}`	`_{{ QMERGE FIELD device_ _c.o_device _od _manufacturer \* MERGE FORMAT }}`	`_{{ MERGE FIELD service _plan_device _device_cost \* MERGE FORMAT }}`	`_{{ MERGE FIELD service_plan _device_ device _status \* MERGE FORMAT }}`	`_{{ MERGE FIELD service_plan _device_list _price \* MERGE FORMAT }{ MERGE FIELD Service _Plan_ Device_end }}`

{ MERGEFIELD agreement_service_plan_section_end }

X-Author and Merge Server components are able to resolve these nested grandchild relationships using the section start and end tags. If a start section tag is present, any child level items after the section start tag and before the end section tag (i.e. agreement service plan items in the example above) are assumed to be normal child level items, and within the section tags - any merge fields in tables with the start and end tags for line item levels (such as agreement service plan devices in the example above) denote grandchildren items at the agreement or parent object level. These items are also child items via a lookup relationship to the true children at the parent level.

Section blocks can also be maintained manually by the template designer as well as line item start and end tags can, but it is preferable to do this using X-Author.

Note:

The repeating section design discussed above is based on Word fields. Word allows Word fields to be inserted almost anywhere in a document; however, the start field should be inserted before the beginning of a paragraph and the end field should be inserted after a paragraph is ended, otherwise you will get errors generating the agreement.
This design supports conditionally marked text inside of sections without any changes. Also qualified merge fields inside a table being inserted inside section tags are supported (lookups for 3-level objects); but line item conditions inside tables are not supported.
You cannot have sections nested inside of one another and you cannot have grandchild level objects defined within a section unless they are defined within a table.

Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Support for Nested Child Level Merge Fields (Pre-FX2)

Section Tags

Agreement (Level 1)

Agreement Service Plan (Child of agreement) (Level 2)

Agreement (Level 1)

Agreement Service Plan (Child of agreement) (Level 2)

Agreement (Level 1)

Agreement Service Plan (Child of agreement) (Level 2)_2

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Agreement (Level 1)

Agreement Service Plan (Child of agreement) (Level 2)

Agreement Service Plan Device (Grandchild of agreement) (Level 3)

Footer Section

Explore