Performing distributed operations on join forms

The information in this topic is applicable only for on-premises deployments.

The Distributed Server Option can perform all types of distributed operations—transfer, update, return, and delete—on join forms.

Before performing a distributed operation on a join form, complete these tasks:

• Add the following field to at least one of the join form's underlying forms:

  ARDS_RESERV_DISTRIB_UNIQUE_ID (field ID 322)

• Add field ID 322 to the join form from one of the underlying forms.
  Field ID 322 is a reserved field that has characteristics similar to field ID 112, the Assignee Group field. A join form can contain only one instance of each reserved field.

• For CREATE and MERGE operations that trigger  actions on join forms, create workflow that populates field ID 322 with the request's joinEntryID before the  action occurs.
  The joinEntryID is composed of the request IDs of both underlying forms, separated by a vertical bar (|).
  The system uses the contents of field ID 322 to populate the Source ID field of the Distributed Pending form.

  Evaluate the workflow to determine whether you need to protect any of the merge filters from the  user. If you do, use this qualification: $USER$ != 'Distributed Server'. For more information about the  user, see Configuring-a-password-for-the-DSO-user.

• Create workflow to propagate the distributed data to the underlying forms.

For distributed operations involving join forms, the  logs do not include the Request ID of the request created or modified in the target form.