Linked fields are used throughout Agiloft to connect People to Companies, Contracts to Departments, workflows to Contracts and Tasks, and in many other places. These fields can be strict links, only allowing users to choose one or more existing records in the source table, or loose links, allowing users to either choose from existing records or enter new values without creating new records in the source table. This article focuses on loose links and discusses their advantages, disadvantages, best practices, and common use cases.

Typical Use Cases

• Entering contract signers who don't have existing records in the External Users table
• Entering a shipping or billing address that is different from the Location records in the system
• Changing default pricing in a Products background table while preserving the snapshots of custom pricing for products and quotes that reference those products
• Troubleshooting imports

Terminology

The following terms are used in this article:

Enabling Loose Links

You can enable loose links on the Mapping tab of the Field wizard for all linked field types. By default, linked fields are created as strict links, so to allow loose links you need to select the “Allow entries not in source table” option.

Overview of Loose Links

Most of the time, strict links are the better choice for linked fields because they make sure that all the related information in the system is connected and automatically updated when the source table's information changes. However, loose links have some advantages that make them the better option in some limited cases. Let's review these advantages, as well as cover the main disadvantages of allowing loose links.

Advantages of Allowing Loose Links

When users need to enter information that might not already be in the system, and you do not want to require them to create new records, loose links are a better choice. This can often streamline business processes.

For example, a customer might have regular contracts with a large company in which the party signers are constantly changing. If the signers don't already exist in the system, it might be easier to allow contract managers to simply enter their names and contact information rather than have them create a new External User record. This is the reason that linked fields like 1st Party Signer Name and 2nd Party Signer Name in the Contracts table of the Standard System Demo are configured as loose links.

Loose links can also be useful in situations where the value of a field frequently changes from a default value. This allows users to make changes to the default value in the current record without affecting the fields in the source record.

For example, a set of products might be brought into a contract as a linked set from a background table. Each product would have a default price, but individual contracts are often negotiated with custom pricing. Creating a loose link for the Price field would allow each contract to preserve accurate pricing records, assuming that the link is configured so that it is not updated once set. This would also preserve the default price in the original Product record, making it possible to calculate the number of times a product’s default price changed or by how much it changed.

Disadvantages of Allowing Loose Links

The convenience offered by loose links needs to be weighed against the possible disadvantages. For example, allowing a loose link for contract party signers might result in cases where an impatient contract manager might not find a party signer record already in the system due to a spelling error, so they simply enter a new name. If there were reports to run or related tables displaying all the contracts with this signer, these lists would be incomplete because the system treats the misspelled name as a different person. The same concern also exists for other kinds of records, such as Company or Location records.

The other main disadvantage of allowing loose links is more obvious, which is that in many cases you don't want users to enter information that doesn't already exist in the system. You can prevent this with certain display types, but other times your linked data might have many possible values, such as the Requester Name field in the Standard System Demo, so you want to use a text box for the field display. In this case, you don't want to also use a loose link because you want to make sure that all contract requesters have a record in the People table.

One further consideration is that loose links sometimes affect how quickly changes are reflected. For example, an update to an Employee record might take extra time to appear in a linked Contract record if the relationship is a loose link, even if the linked field is configured to update automatically. This can be mitigated by creating a rule that forces an update. In the given example, you might create an Edit rule on the Employee table that uses a Linked Record action to update the field in Contracts.

When Creating New Records is Preferred

In cases where it is preferable to have the user create new records, one solution is to give the user the ability to create these records directly from the table in which they are currently working. Rather than creating a loose-linked set of fields from another table, you could create a parallel set of fields in the current table that require the minimum information necessary for the new records. You could then configure an action button that converts these fields into new records.

You can see this configuration in the the Contracts table of the Standard System Demo. On the Details tab, users have the option to enter new company and location information for the current contract. This information is converted into Company and Location records when the user clicks Create New Company. The user enters basically the same information that they would have in using a loose-linked set, but creating new records makes it much easier to find duplicate entries, run reports, and maintain an audit trail.

Key Questions

Think about the following questions to help determine whether you should allow loose links for a linked field.

1. Do users need to enter information that isn't already in the system? In this case, you must use a loose link with an appropriate display type or allow the user to create new records in the source table. Ask yourself whether creating new records in the system is necessary or adds value. If not, fields with loose links can be easier for users to use.
2. Does a linked field contain a value that frequently changes? If so, allowing loose links might be the correct choice, especially if you don't want users to create entirely new records. If one or two fields in a linked set frequently change, and the rest of the fields in the set usually stay the same, it's often a good idea to allow loose links, making sure to choose appropriate display types for the linked fields or enable quick editing.
3. Is the data in the linked field included in a report or related table? If so, weigh the potential for user errors against the desire for accuracy in the report or related table. When you allow loose links, you introduce the possibility that a user might enter data in the system when they really shouldn't, which can cause unintended consequences. If it's critical that your reports or related tables are always completely accurate, avoid loose links and require the user to create new records.

Use Cases

The following use cases highlight some of the advantages of loose links in specific situations. 

Billing and Shipping Addresses

Frequently, the main address of a company is not the same as either the billing or shipping address, and these addresses might not be the same either. Imagine a customer whose billing and main addresses for all contracts also serves as the default shipping address for deliveries. However, sometimes these contracts require a different shipping address, usually to specific locations outside the company that will not be used again or used only infrequently.

In this case, creating a new Location record for every new shipping address would cost considerable time for little benefit. Instead, creating a loose link to the Locations table from the Contract record, which defaults to the value from the Billing Address field, would automatically populate the Shipping Address field with a value that's often relevant. If changes needed to be made, users could make them quickly in the Contract record without affecting the linked Location record.

Company Contacts

Some contracts require the flexibility to be signed by one of many party contacts. The best practice is to enter frequent signers in the system, but a loose link to the External Users table allows other parties to also be included in the contract. In the Standard System Demo, 1st Party Signer and 2nd Party Signer are set up as loose links, as are the fields for Internal Signers. Additional counterparty or internal signer fields can be modeled on these existing fields as needed.

For example, a company's contracts might require fields for a 2nd Internal Signer when the contract meets certain conditions, such as contracts over a certain dollar value, contracts that require specific government compliance like HIPAA or the ADA, and so on. This second signer might be an executive in some cases, a compliance officer in others. Rather than setting up a filter that could pick out the relevant signer pool, it might be better to configure the fields in the linked set as a loose link to the Employee table. This would allow the contract manager to simply enter the second signer's name, title, and email address.

Custom Pricing for Products

Products in a background table with standard pricing may need custom pricing when contracts are negotiated or quotes are generated. Consider a very simple case where a contract requester needs to select the products covered by a contract. The selected products could be shown as a Link to Selected Fields with multiple values enabled that would display like an embedded table. By configuring this linked set as a loose link, users could initially populate the products with their default prices and also allow price adjustment within a Contract record, possibly as a quick-editable field directly from the embedded table. 

This configuration requires you to select the "Do Not Update" option on the Mapping tab of the Field wizard. This would ensure that changes to the Product record, like price increases, are not pushed into existing Contracts or Quotes that should continue to reflect their negotiated prices.

Usually in a case like this, it would be better to create both a background table for Products and an intermediate table called something like Contract Products to hold individual records associated with each contract. Each Contract Products record would have a set of linked fields to the Products table that would include things like the Product Name, Description, Item Number, and Price per Unit. When a contract required selecting products, new Contract Product records would be created, but configuring the link to the Products table as a loose link would allow the same kind of custom pricing without affecting the default price in the Product record. Likewise, changes to the default pricing of a Product would not automatically update prices offered for existing Contracts.

Displaying Linked Fields

In a case like this, it is probably a good idea to restrict the linked fields that can be changed. For example, in most use cases, the ID and Product Name should not be editable in the same way that the Price per Unit would be. You can use the options on the Display tab on the Field wizard to make certain fields in the linked set function as strict links. Displaying the Product Name as a List of Values will require a user to select existing product names, regardless of the "Allow entries not in source table" setting. However, setting the Price per Unit display to Box Only will allow users to edit the field value and input new custom pricing.

Troubleshooting Imports

In some import situations, it might be helpful to use loose links temporarily so that imports do not fail. For example, when importing Employee records, it might be helpful to make linked sets like Department Name and Department Head loose links if the Department table does not yet have any records. Similarly, consider temporarily using loose links when importing External User records, because their Department Names and Heads will certainly be different from existing records in the Department table.