Contents

Introduction
Parallel vs. Serial Routing
Configuring Serial Signature Requests
Serial Routing Example

Introduction

Here is a comparison of Parallel vs. Serial routing:

Parallel Routing (traditional mode in CATSWeb)

• All signature requests are generated when the Request Signatures option is selected in a record submission.
• All users immediately receive E-mail notifications regarding their signature requests.
• All users can immediately see their signature requests in their Hot List.
• All users can immediately see their signature requests in their Personal and Department task lists.
• Due dates for the signature requests are set when first generated (based on the Due Date Increment setting) and do not change.
• A user may sign at any time to satisfy their signature request.
• Signature Request Rules operate on all signature requests.

Serial Routing

• All signature requests are generated when the Request Signatures option is selected in a record submission. The signature requests are flagged as either Active ("Ready to Sign") or Pending. Initially, only the requests from the first serial step are flagged as Active.
• When all signature requests are satisfied for a particular serial step, the requests associated with the next serial step are transitioned from Pending to Active.
• Users only receive E-mail notifications regarding their signature requests when they become Active.
• Users can only see their signature requests in their Hot List if they are Active.
• Users may specify a Request Status setting in their Signature Requests task lists (both Personal and Department) to filter the requests based on their Active or Pending status.
• Due dates for all signature requests (Active and Passive) are initially set based on the Due Date Increment setting for the signature controlled operation.
• Due dates for Pending or newly Active signature requests may be automatically revised as prior serial steps complete.
• A user may only satisy their signature request (by signing) when the request is Active. If a user signs when their request is still pending, their signature will be accepted, but it will not satisfy the signature request.
• Signature Request Rules only operate on Active signature requests.

Back to Top

Configuring Serial Signature Requests

Configuration is primarily performed via settings in the list items that make up the Required Signature List. The Required Signature Name Fields setting should not be used and should be cleared for serial signature requests, as these fields may instead be identified within the Required Signature List itself. Other signature controlled operation settings function the same as they do with parallel signature requests.

The Required Signature List utilizes list item settings in the following ways:

• Sequence - Specifies the order of the serial steps. As with order parameters used with field definitions, the sequence may skip values (ex: 100, 200, 300...), but may not use a value of 0 (zero). The lowest non-zero sequence number becomes the first step in the serial process. The same sequence value may be used for multiple list items to include many signature requests in the same serial step (thereby creating a combined serial/parallel routing in which all users within the serial step may sign in parallel).
• List Item - Specifies either a literal Employee Name (ex: Bob Jones), or specifies the name of a field in the record which contains an Employee Name. When specifying the name of a field, enclose the field name in square brackets ("[]") like this: [EnteredBy]. Specifying a field name is similar to specifying Required Signature Name Fields for parallel requests, but allows the Sequence and other list item values to be applied to the name in the field for serial signature request processing. As is the case with parallel requests, duplicate names are automatically removed when the signature requests are generated, whether the names are explicitly in the list or contained in referenced fields.
• Item Selector - Not used, reserved. Leave this setting blank.
• Extra Data - Specifies an optional Due Date Increment (in days) to be applied to the newly Active signature request at the time the prior serial step completes. The new due date for the signature request will be the specified number of days in the future (or past for negative values) relative to the current date when the prior serial step completed. Leave the setting blank or enter a 0 (zero) if no due date incrementing is desired.
  
  This setting's intent is to avoid "penalizing" a user when earlier users respond late to their signature requests. It allows each user to receive a revised due date that is set relative to the date when their signature requests actually become active.
  
  Note that the largely irrelevant due dates for Pending (inactive) signature requests are also adjusted by this offset when earlier steps complete. Once a signature request becomes Active, the due date is no longer adjusted via this setting. Further due date adjustments may only be made by Signature Request Rules.

Serial Routing Example

Here is a sample Required Signature List with its serial signature request routing explained below:

Bob Jones is alone in the first serial step at Sequence = 100. Bob does not have a due date increment specified in Extra Data and does not need one: since he is part of the first serial step, the due date for his signature request will be set per the Due Date Increment setting for the signature controlled operation. When signatures are requested for a record, Bob will receive an immediate E-mail notification regarding his signature request, and it will immediately appear in his Hot List.

Users who view the record at this point will see Bob's signature request color-coded with the "Ready to Sign" color. The other signature requests will be color-coded with the "Pending" color.

The second serial step (Sequence = 200) has two users identified: Sally Fisher, and whoever is in the Text1 field of the record when signatures are requested (we'll assume it is"John Doe" for the remainder of the example). Sally and John receive their notification E-mail immediately after Bob Jones applies his signature to complete step #1. The due date for John's request will be 2 days later, since Extra Data is set to 2 for the [Text1] item. Sally's due date will be 3 days later. Sally and John may now sign in any order, as both their requests will be color-coded as "Ready to Sign". Sally and John are operating in parallel for this serial step.

When the last person from step #2 has signed (Sally or John), the user identified by name in the Text3 field will have their signature request activated. The due date will be set to 1 day after the last person from step #2 signed. When this final person adds their signature, the signature controlled operation completes. Completion of the operation happens in the same way as it would for parallel signature requests.

Back to Top