Note: User Reference Chains must be enabled in your account to use them in Workflow Designer. In addition, you must purchase access to Ironclad's public API to configure the user attributes for this feature.
Please contact support@ironcladhq.com to enable User Reference Chains in your account.
Often, contract approvals and required signatures are based on a company’s hierarchy. For example. WonderWeb Inc. needs to build an Order Form workflow that requires a department head’s approval. They can manually configure this by adding “Department” questions to their launch form combined with conditional role assignments in Workflow Designer, or they could use user reference chains.
Building on the above example, user reference chains would enable WonderWeb Inc. to use a group of department heads so that when anyone launched a workflow, the department head in their hierarchy is automatically assigned as the approver.
Using user reference chains, you don’t need to update your workflow when users change within your organization. For example, WonderWeb Inc. has an employee who transfers departments, or a department head that is replaced, or a new department entirely. In these scenarios, having a user reference chain already in place makes the transitions seamless, for as SCIM updates a user’s attributes as well as the various groups that users are assigned to, these existing user reference chain infrastructure is updated.
Determine Approval and Signature Hierarchy
There are two methods to establish the “user relationship”-type attribute:
Option 1: Management Chain
Send an attribute with each user that specifies that user’s manager, which Ironclad then uses to construct a chain that leads to the relevant signer.
The caveat is if a user within that chain does not exist, the chain is broken. For example, WonderWeb Inc. has a management chain that contains the levels Sr. Manager > Director > Sr. Director > Vice President. If the signer for a specific agreement is “Vice President”, but the “Sr. Director” user is not present in the workflow submitter’s management chain, the corresponding “Vice President” is not identified. In this scenario, Ironclad selects the default user within that group as the signer.
Option 2: Direct
Send an attribute with each user that specifies exactly who is to be assigned to a hierarchical role. For example, if WonderWeb Inc. has designated points-of-contact that are independent of the workflow launcher’s direct management chain, such as a Regional General Manager, then directly mapping users to other users can bridge those gaps.
The advantage to this approach is that it works even if a user is missing from a management chain. The downside is less information about the management chain is available in Ironclad.
If an attribute is filled with a user who does not exist as an Ironclad user, Ironclad selects the proper signature group and uses the default user from that group.
Group Creation
There are two ways to create and manage groups:
- Create and manage groups from the IdP such as Okta.
- Create and manage groups in Ironclad’s Company Settings.
If, for example, a signature hierarchy consists of multiple management levels, such as Director, Sr. Director, Vice President, etc., each management level should exist as its own group in Ironclad. For direct mapping, make sure there is a group of those individuals.
Workflow Designer Configuration
- Create a group for the role in Workflow Designer.
- Select the group that you created such as Managers.
- Select the attribute that will drive the reference chain. For example, “managerEmail” or “regionalGeneralManagerEmail”.
Assignment in the Event There is No Matching User
The default user in the assignable users and groups is assigned if:
- The management chain is broken because one link corresponds to someone who is not a user in Ironclad.
- A direct reference points to a user that is not in Ironclad.