Page tree
Skip to end of metadata
Go to start of metadata

Creating Records from a Process Table

This article discusses options for designing an interface to create records from a process table. When you have linked fields in a process table record, users typically want the option to create a new record in the other table without leaving the current record. For instance, a user might want to create a new Asset related to a Service Request record they're working on. Several approaches can accomplish this:

  • A linked field with a search icon
  • The New button in a Related Table
  • An interactive conversion using a rule
  • A silent conversion using a rule
  • A conversion using an action button

The best approach depends on a variety of factors, which we'll cover in the rest of this article.

Typical Use Cases

  • Converting a Lead into a Company, Opportunity, Location, and Person
  • Creating a Company, Location, and External User within a Contract record
  • Adding a new Person when working on a Contract
  • Converting information in a Task to a Time Entry

Linked Field with a Search Icon

Any linked field with a search icon allows users to create records in another table, provided the user has permission to create records in that table. This is the easiest and quickest solution to implement, but it doesn't offer some of the useful functionality of other approaches. When users create new records this way, they typically select the record after creating it to populate other fields in the parent record.

Advantages

  • It's easy to implement.
  • The user has the opportunity to fix errors in the newly created record because they are shown any validation errors.
  • It uses less space in the parent table than most of the other approaches.

Disadvantages

  • Users need to be trained to use the lookup window to create the new record.
  • If the linked table has subtables, the user might create a record in the wrong subtable.
  • After creating a new record, the user must select it to include its values in the parent record.
  • The new record can't automatically pull values from the parent record.
  • The user always requires permission in the linked table to create new records.

New Button in a Related Table

When a Related Table includes a New button, users can create new records in the linked table by clicking the button, which opens a record form in the table. To configure whether a Related Table includes a New button, set up an action bar in the Table wizard, and then select that action bar on the Display tab when you configure the Related Table. If the user doesn't have permission to create records in the linked table, the button is automatically hidden. 

Advantages

  • It's relatively easy to implement.
  • It's fairly intuitive for users and requires little training.
  • It uses very little space in the parent table because records in the Related Table are stored in the linked table.
  • The user can fix errors in the newly created record because they are shown any validation errors.

Disadvantages

  • The only fields automatically included in the new record are the fields that establish the linked relationship for the Related Table. Other approaches allow you to include as many fields as desired.
  • The parent table must have incoming links from the linked table so that the Related Table can be created.
  • The user always requires permission in the linked table to create new records.

Interactive Conversion Using a Rule

An interactive conversion using a rule allows users to automatically create new records by triggering a rule that contains a Data Conversion action. When a conversion is interactive, it means the user is shown the conversion dialog or new record form during the conversion process, which allows the user to make edits to the data when the new record is created. 

Permission to create new records depends on the type of interactive conversion. If the user is shown the conversion dialog, they don't need permission in the target table to create new records, but they do need such permission if they are shown the new record page.

Advantages

  • Field values from the parent record are automatically included in the new record.
  • Multiple new records in different tables can be created and linked to each other.
  • Users can edit fields and correct mistakes when the new records are created.
  • If the conversion dialog is displayed, users can be given the option to reject a conversion entirely.
  • If the new record form is displayed to users, it's straightforward and intuitive for them.

Disadvantages

  • Testing the rule requires extra configuration time.
  • It requires more space in the parent table than some of the other approaches.
  • If the conversion dialog is displayed, users typically need some amount of training to ensure they understand how it works.

Silent Conversion Using a Rule

Like an interactive conversion, a silent conversion using a rule allows users to automatically create new records by triggering a rule that contains a Data Conversion action. The difference is that silent conversions create new records without any user intervention or confirmation. Users can trigger the system to create records this way even if the user doesn't have permission to create records in the target table.

When you create a silent conversion using a rule, users might not even know that a new record has been created, unless they're admins who are familiar with the system's configuration. To prevent any unintended consequences with usability, keep this in mind when you use this option.

Advantages

  • Field values from the parent record are automatically included in the new record.
  • Multiple new records in different tables can be created and linked to each other.
  • It requires no training for users to create the new record.
  • Users don't need permission in the target table to create new records.

Disadvantages

  • All required fields in the target table need to be carefully mapped from the process table so that records are created without any errors.
  • Required field validations do not run in the target table, so users cannot correct any mistakes in the newly created records.
  • Testing the rule requires extra configuration time.
  • It requires more space in the parent table than some of the other approaches.

Conversion Using an Action Button

A conversion using an action button combines an action button with a Data Conversion action to allow users to manually create new records in another table. Depending on the conversion's configuration, users can be shown a confirmation of the conversion, the new record form, or nothing at all. If you show the new record form, the user requires permission to create new records in the target table.

Conversion using an action button is one of the most user-friendly options, but it can take significantly longer to build than the other approaches. The best configuration of this approach requires you to spend time creating a set of duplicate fields to hold the information for the new record. However, if you incorporate this approach in a design that's carefully thought out, the result is a system that's extremely intuitive for users and unlikely to result in errors.

Advantages

  • It's intuitive for users. This is especially true for end users who will not access the system frequently and will not remember details from the training, and for end users who will not take the training at all.
  • Multiple new records can be created and linked to each other.
  • Field values from the parent record are automatically included in the new record.

Disadvantages

  • Creating and testing all the necessary fields and rules takes significantly longer than the other options.
  • If you need to create a lot of duplicate fields, it increases the space required in the parent table.
  • If you don't display the new record form, required field validations do not run in the target table when records are created, so users cannot fix errors in the newly created records.
  • If you don't display the new record form, you need to carefully ensure all required fields in the target table are mapped from the process table so that records are created without any errors.

Key Questions

When you're implementing a system, think about its requirements to determine which approach is best for your situation. You might need to balance competing needs when making your choice. Use the following questions as a guide to help you with your decision.

  1. How many users will be trained on the system? If relatively few users will complete training, you might want to avoid a linked field with a search icon. Users can make errors because they're not properly trained on the functionality. If you're especially concerned about users making errors, or many users won't complete the training, a silent conversion using a rule and a conversion using an action button are the best choices.
  2. How often will users create new records? If users create new records frequently, think about taking the time to build a conversion that uses an action button, which is the most intuitive and user-friendly option. A silent conversion using rule is another good choice for records that are created often. If you use one of the other approaches, ensure the interface is clean and well-designed to make creating new records quick and simple.
  3. Is space in the parent table limited? A linked field with a search icon and a Related Table with a New button use the least amount of space. If space is at a premium, consider one of these approaches.
  4. How much time do I have to finish the implementation? If you have the time available and the use case is appropriate, strongly consider a conversion using an action button. This option is typically the most attractive and intuitive for users, but it takes longer than the others to build.
  5. Do I need to automatically include field values from the parent record in the new record? If so, a linked field with a search icon cannot be used. This approach doesn't allow you to automatically include field values from the parent record, so you need to use one of the conversion options, or a Related Table. If you use a Related Table with a New button, the included field values are limited to the fields used to establish the linked relationship.
  6. How many fields are required in the new record? If the new record has many required fields, consider using a linked field with a search icon, a Related Table with a New button, an interactive conversion using a rule, or a conversion using an action button that displays the new record form. These approaches run required field validations on the newly created record and allow the user to correct any errors in the data. If you use a silent conversion using a rule or a conversion using an action button that doesn't display the new record form, be careful that records aren't created with validation issues.

Sample Scenarios

Review these sample scenarios to see how each approach has been used in real-life situations.

Linked Field with a Search Icon - Choosing a Requester in a Contract 

In the Contracts table, all contracts typically have a requester. The requester information includes fields for the Requester Name, Requester Email, and others, which are part of a linked set to the People table. Notice the lookup display icon next to the fields.

When the user clicks the lookup display icon, a search window for the People table opens. The user can select an existing individual from here and populate the fields in the contract with that individuals's information, or they can use the drop-down menu to create a new user record in the People table.

If the table has subtables, which the People table does, the user needs to be trained to select the correct table when they create the record. If they select the External User subtable but the requester is really an Employee, it can create problems with data organization and retrieval.

After the user selects a table, a new record form in that table opens. The user can then enter information for the new person and save the record. If the record has validation errors, such as required fields that are incomplete, the system does not allow the user to save and create the record until the validation error is corrected.

After the user creates the new record, it appears in the search window so that the user can select it and populate the linked fields in the contract with the record's data. 

The user must manually select the newly created record to populate the linked fields; the system does not do this automatically.

Related Table with a New Button - Adding a Problem from a Change Request

Records in the Change Requests table have a Related Records tab that contains several Related Tables, each of which displays records in other tables that are related to the current change request. One of those Related Tables displays records from the Problems table. When users click New, the system opens a new record form in that table.

When the record form opens, the only field values included from the change request are those fields that create the linked relationship necessary for the Related Table. In this case, that's two fields: Change Request ID and Change Summary. The user must manually complete the other fields. If there are validation issues, the system prevents the record from being saved and the user must correct the errors.

Once the user saves the record, the record is created in the Problems table, and it appears in the Related Table in the change request.

If this is a new change request and the user cancels out of the record at this point, the record in the Problems table is still created. However, the linked fields that were populated in the Problem record appear to link to the now canceled change request, and they do not function if clicked.

Interactive Conversion Using a Rule - Converting a Lead into a Company, Location, Opportunity, and Person 

Lead records have a Status field that's used to convert leads into Company, Location, Opportunity, and Person records. When a salesperson expects a possible sale, they convert the lead to reflect that possibility. They do this by selecting the Converted status and saving the Lead record, which triggers a rule that runs a Data Conversion action.

This interactive conversion is configured to open the Conversion dialog when the conversion begins. The user is shown fields on this dialog that were chosen as editable when the conversion was configured, and the user can make changes to those fields as they see fit. The user can also reject a conversion entirely for a given table, which is another configurable option of the conversion. 

The records are converted when the user clicks Convert. If a required field is left blank, the system prompts the user to enter a value before the conversion runs.

A screen with the conversion results appears after the conversion is completed. The screen lists all the records that were created, or whether an existing record was updated based on a matching value. 

If a validation fails—for example, because a field that requires a unique value has a duplicate value—the conversion for that record is cancelled and reported on this screen. To create a record that failed to convert, the user must restart the conversion with a different value for the invalid field.

Assuming that all the conversions succeed, a new record is created for each conversion mapping contained in the Data Conversion action. In this example, that means new Person, Opportunity, Company, and Location records are created, which are also linked to one another.

Silent Conversion Using a Rule - Converting a Contract into an Attachment

The Contracts table contains several hidden fields by default, including Transitional Contract Files, Transitional Attachment Type, and Transitional Attachment Title. The Transitional Contract Files field is especially important. It's used to temporarily hold files generated from print templates and files included as attachments in inbound email to the Contracts table. For this use case, we're going to focus on email attachments.

When a Contract record is updated by email and the email includes attached files, the files are automatically placed in the Transitional Contract Files field. This is possible because of two settings in the inbound email configuration for the Contracts table.  These settings are accessible by going to Setup > Email and SMS > Configure Inbound Email, editing the Contract table's configuration, and selecting the Email Updates tab.

A rule in the Contracts table is set to run whenever the Transitional Contract Files field has changed and contains a value. The rule also contains two actions. The first action contains the Data Conversion action that creates the Attachment record and maps the relevant fields. The second action removes the file from the Transitional Contract Files field so that other updates don't create records with that same file appended.

When the rule creates the new Attachment record, the user is not shown any confirmation or dialog because the update came from an email, regardless of the conversion setting. In this case, it's not important that the user is notified because they don't need to make changes to the record or otherwise interact with it at this time.

Conversion Using an Action Button - Creating a New Company and Location from a Contract

All records in the Contracts table are associated with a company. Records in the table use the Contract Party Entry field to determine whether the user searches for an existing company or creates a new company. The Contract Party Entry field is a Choice field that uses radio buttons and has two choices, with Existing Company selected by default. This leads the user to search for an existing company before attempting to create a new one.

If the user wants to create a new company, they select the New Company option, which hides the linked fields and displays several local, visibility dependent fields used for the conversion. After the user enters the required information, they click Create Company to create records in the Company and Location tables.

Notice that the linked fields from above and the local fields used for the conversion are displayed with the same field labels. This is possible because the field labels of the local fields are actually input instructions. Their real field labels are hidden.

In this case, records are created in the Company and Locations table without any user intervention or confirmation. The newly created company is then automatically selected in the current Contract record, and the linked fields are populated with the information the user entered when creating the company.

Explanation of Functionality

This conversion using an action button contains many moving parts that might not be immediately apparent. The approach can seem complex when we discuss how it works, but it's attractive because it allows users to create records in multiple tables that are linked to the current record, and it leaves little to no room for user error. It's also intuitive and allows users to create the new records completely from within the current record, without any new dialog prompts or windows.

Explanation: Conversion Fields

The local fields used for the conversion are duplicate fields that already exist as linked fields in the Contract record. The linked fields link to an existing Company record, and the local fields are used for entering information for new companies. Requiring duplicate fields in this way does add to the configuration time.

Fields that are required in the Company and Location records are required in the local fields used for the conversion. This ensures that the conversion completes successfully without any validation issues.

The conversion is configured to match on the Company Name field in the Company record. This means that if someone creates a company that already exists based on a matching name, the existing record is updated instead of a duplicate being created.

In the Location table, duplicate records are prevented with the Company / Location field, which requires a unique value and is a compound field of the Company Name and Location Name fields. If a user enters an existing company and an existing city, the conversion is prevented due to a uniqueness requirement error.

Along with the details supplied in the local fields already shown, the conversion also maps the contract's ID into a Contract Source ID field in both the Company and Location records. This allows the system to establish a link from the new records to the contract. This is also a field that a rule uses, which we'll discuss in a section below.

Explanation: Action Button

The action button begins by setting the location name of the new company by using a formula. The formula combines the New Company Name and New Company City fields to set the value of the New Company Location Name for Conversion field. This field, which is hidden by default, maps to the Location Name field in the Location table.

If the user clicks the action button and tries to create a company that already exists but the location is new, the new location is added to the existing company's record in a Related Table.

The action button runs two more actions. The next is the conversion itself, which maps the fields from the Contract record to the fields in the Company and Location records defined in the conversion mapping. Lastly, it removes the values from the New Company fields in the Contract record and resets the radio button to the default value of Existing Company.

Explanation: Rules

The Company table contains a "Create: Contract Source Actions (web, API)" rule that runs when records are created in the table. It uses a saved search to filter the records it operates on, finding only records whose Contract Source ID field is not empty. Because a contract's ID is mapped to the Contract Source ID field during the conversion, the rule operates on every Company record created from a contract.

The rule in the Company table contains two actions. It uses a Linked Record action to update the linked contract's Company ID field with the ID from the new Company record. It also runs an Update Fields action to update the Company Roles field in the Company record with the value from the Primary Role field, which was mapped during the conversion.

The Location table contains a very similar rule, but instead of updating the Company ID, it uses a Linked Record action to update the linked contract's Location ID field with the ID of the new Location record. It also contains another Linked Record action that updates the Main Location ID field in the linked Company record.