Forms Generation

The most common use case for kicking off the forms generation process is to create a custom button on a Salesforce record.
Now that configuration is done, it’s time to start generating forms!

To set your Button:

1. Create a custom button. 

2. Ensure your content source is a URL.
   
   URL Base
   
   The URL should start as /apex/OrchMM__QuikFormsListPage. This is the minimum requirement for the URL on the button.

   

   If you only have this part the whole process still works. Adding the optional parameters greatly improves process efficiency.

   
   URL Parameters
   
   The URL parameters are optional. If they are included they pre-populate the Role Map screen with the corresponding records. On the Field Mapping screen, you mapped Quik form fields to fields from various Salesforce objects. These parameters tell Mix which specific record (using a record’s ID) to get data from for each Salesforce object type on each role.
   
   

3. Add a question mark (?) after the URL Base: /apex/OrchMM__QuikFormsListPage.

4. Parameters take shape. 
   These parameters take the form: {role instance (1-10)}{role name}.{SFDC Object}={Object’s ID}
   For example, 1acc.Account={!Account.Id}. The User Defined fields are a little different in that they do not have a role instance number.
   For example, User.Contact={!Account.Primary_ContactId__c}
   

   

   When building the button, the fields inserted into the URL must always come from the object you are building the button on.

   These parameters correspond to the roles and fields you have mapped on the Field Mappings screen. Any number of parameters can be added. When building the URL in a button, both native and custom objects may be used.

   

   Note

   If you wish to use the SFDC object in a parameter, it must be used at least once in the field mapping screen under the corresponding role.

5. Click Save.

6. Add the button to the page layout. For example: Let’s suppose the Account object in my org has the following fields:
   

   Primary_Contact__c	Lookup(Contact)
   Contact_Spouse__c	Lookup(Contact)
   Beneficiary_1__c	Lookup(Contact)
   Beneficiary_2__c	Lookup(Contact)
   Contingent_Beneficiary_1__c	Lookup(Contact)
   Case__c	Lookup(Case)

Let’s also suppose that I have mapped the various fields on the Field Mapping screen. If I wanted to create a button on the Account screen that would pre-populate all these fields automatically here is what my button’s URL would look like:

/apex/OrchMM__QuikFormsListPage?1acc.Account={!Account.Id}&1acc.Case={!Account.Case__c}&1rep.User={!Account.OwnerId}&1own.Contact={!Account.Primary_ContactId__c}&2own.Contact={!Account.Contact_SpouseId__c}&1ben.Contact={!Account.Beneficiary_1Id__c}&2ben.Contact={!Account.Beneficiary_2Id__c}&1cben={!Account.Contingent_Beneficiary_1Id__c}&user.Contact={!Account.Primary_ContactId__c}&user.Account={!Account.Id}&user.Case={!Account.CaseId__c}

That is a lot to take in, so let’s break it down parameter by parameter:

1acc.Account={!Account.Id}

1acc: 

This part of the parameter tells Mix that I am creating a mapping for the first acc (Account Information) role. These shortened role names can be found in the parenthesis in the Role drop-down menu on the Field Mapping screen. As you can see, I have only added one instance for the acc role in the URL. Quik allows up to 10 instances for each role, but I am making an assumption that for the majority of the forms, there is one acc role. If I discover later that I am running into forms that use more acc roles, I can always go back to the URL and add additional role instances.

.Account: 

You can see that for the Account role on the Field Mapping screen mapped in two fields. One field is mapped to the Account object’s Account Number field. The other is mapped to the Case object’s Case Number field. In this parameter, I am telling Mix that the following ID corresponds to the Account object.

={!Account.Id}: 

Since I am creating this button for the Account screen every ID comes from the Account object. In this case, I am grabbing the Account object’s ID. Taken together this parameter tells Mix to populate the first account role instance (1acc) Account object fields with data from the Account record with the specified ID from the Account’s ID field ({!Account.Id})

1acc.Case={!Account.CaseId__c}

acc: 

Again we’re mapping to the first acc role instance.

Case: 

This time we’re going to specify an ID that corresponds to the Case object. Remember from Screenshot 1 above, I have mapped fields on the Account Information (acc) role to both the Account object and the Case object.

={!Account.CaseId__c}

Again, since we’re building a button for the Account screen, we need to pull an ID from the Account object. In this example, I have created a custom field called Case that is a lookup field to the Case object. Be sure to choose the ID field in the Insert Field drop-down menu when creating the button for all lookup fields. Taken together this parameter tells Mix to populate the first account role instance (1acc) Case object fields with data from the Case record with the specified ID from the CaseId__c field ({!Account.CaseId__c}.

1rep.User={!Account.OwnerId}

rep: 

The Role drop-down menu, rep is the role name for the Rep role.

User: 

There are two fields mapped, one is a static value, and the other is mapped to the User object. In this parameter, we’re setting the ID for the User object. Static values show the same static text no matter where they show up on the form and therefore nothing needs to be mapped in the URL for them.

={!Account.OwnerId}: 

The OwnerId field is a standard field on the Account object and is a lookup to the User object. Taken together this parameter tells Mix to populate the first rep role instance (1rep) User object fields with data from the User record with the specified ID from the OwnerId field {!Account.OwnerId}.

1own.Contact={!Account.Primary_ContactId__c}

1own: 

The Role drop-down menu, own is the role name for the Owner role. This parameter is mapping to the first owner role instance.

Contact: 

There is only one Salesforce object type even though there are three fields mapped, therefore we only need to add the Contact object to the URL.

={!Account.Primary_ContactId__c}: 

For the first owner role instance, we are going to retrieve data from the record stored in the Primary_Contact__c field. Since this field in our example is set up as a lookup to the Contact object we must select the ID field to put in the URL. Taken together this parameter tells Mix to populate the first owner role instance (1own) Contact object fields with data from the Contact record with the specified ID from the Primary_ContactId__c field ({!Account.Primary_ContactId__c}.

Other URL Options

skipRoles=true: 

Add this parameter to the URL if you wish to skip the Role Mapping screen during the forms generation process. You may want to do this if all the IDs are present on a single SFDC record and you’ve pre-populated all the IDs in the URL. In this case, you wouldn’t need to manually select any records on the Role Mapping screen and may wish to skip that screen. Doing so would speed up the process.

dealer={some company name}: 

Add this parameter to the URL to predefine the company filter in the forms list.

category={some category}: 

Add this parameter to the URL to predefine the category filter in the forms list.

Choose Forms

The first step when generating forms is to choose which forms to generate. If you have created a button according to the previous section of this document, clicking the button takes you to the Forms List screen.

Quik Form Groups

If you have setup Form Groups in Quik, those Form Groups appear here for selection.

Quik Forms

All individual forms you are subscribed to appear in this list.

Dealer Name Filter

The dealer name filter drop-down menu filters the list of forms by the selected dealer name.

Category Filter

The category filter drop-down menu filters the list of forms by the selected category. To learn more about form categories, see the Other Configuration Options section of this document.

Next

Once you have selected all the forms you would like to generate, click Next.

Map Roles

If you have not chosen to skip the Role Mapping screen, this is the second step in the forms generation process. The table on this screen is populated by all of the roles that appear in the selected forms along with an input field to choose which SFDC record corresponds to a particular role. If you’ve added records in the URL, they pre-populate.

Note

Any roles pre-populated from the URL can be changed on this screen.

Back

The back button returns to the Forms List screen.

Quik Role table

This table is populated by all of the unique roles that appear in the selected forms.

Note

For example, Owner 1 appears on multiple forms, it appears in this list only once and the record chosen for this role is populated on all forms.

Record Search input field

This field is pre-populated with the corresponding record in the URL parameters. You can also change or populate this field by typing in the name of a record. A selection options menu appears after a minimum of three characters. In this example, the Owner role only has fields mapped to the SFDC Contact object, therefore the Record Search field only shows up in that column. If a Quik Role does not have at least one field mapped for the object in the column heading, no SFDC record is searchable. However, the fields corresponding to those roles on the forms are available and editable.

Submit

Once the SFDC records have been selected, click submit.

Note

The SFDC Record fields are not required; if no records are selected the system generates blank, editable forms.