The Microsoft Dynamics Workflow system allows for a highly customizable string of related objects to automate processes within the Dynamics environment. These processes can be manually triggered by a
This document is intended to expose and explain the Adobe Sign objects that have been added in version 7 of the Adobe Sign for MS Dynamics CRM package.
It is not intended as an in-depth explanation of the Custom Workflow system within Dynamics.
Adobe Sign for MS Dynamics CRM supports the creation of custom workflows in the version 7 installation package for the 365 CRM solution only.
This package contains:
- Six Activities, the discrete actions that can be used to create your own custom processes
- Two Actions, ready for use “out of the box”. Excellent reusable processes for multiple workflows
- One Workflow, a functional example (in Draft status) that automatically sends an agreement when an Opportunity is set to "Won"
註解：
Before creating a Workflow, you should have a solid understanding of the form to be signed, and number/order of the recipients to be included in the signature process.
There are multiple options that can alter the signature order, usually by inserting a recipient into the first recipient position, pushing the other recipients down the stack.
Activities are the building blocks of Actions and Workflow, each defining a discrete task that can take input from previous activities or events, and generate output for subsequent activities.
Chaining a series of Activities together creates an Action or Workflow.
There are six Adobe Sign Activities available:
The fields:
Agreement Name – The name of the agreement as it is to be shown in the email messages to the recipients, and as it is referenced throughout the Dynamics environment
Agreement Message – The global message that is added to the email notifications to the recipients
Signature Type – Defines the signature flow enforced by Adobe Sign. Two options exist:
- ESIGN – Uses electronic signatures, applied entirely through a web-connected session. Recipients can use
desktop or mobile platforms to apply the signature - WRITTEN – Used when a physical signature is required. The process asks the recipient to print the file, physically sign the document, scan the document back to PDF format, and upload it back to the system
Set Password to Open Signed PDF – An optional field that accepts a password string which is applied to the final signed document. Viewing the signed PDF requires the password in all cases
Days until Agreement Expires – Any value entered in this field represents how many days the agreement remains signable after it has been created. All recipients must complete their part of the signature process before this timer expires or the agreement is canceled
Sender Signing Options – Governs the recipient signature flow in terms of the sender. Four options exist:
- I do not sign – If the sender is not expected to sign simply because they are the sender
- Remember that the sender can be added as a recipient through other methods, such as a lookup
- I sign first – Inserts the sender of the agreement into the recipient stack as the first signer
- I sign last – Inserts the sender of the agreement into the recipient stack as the last signer
- Only I sign – For processes where only the sender would apply a signature. E.g. Vacation requests
注意：
Sender Signing Options directly impact the signature order of the agreement, and override the Recipient Order value as defined in the AddRecipient activities.
If you have defined a recipient with a Recipient Order value of 1, and then configure the CreateAccount activity to insert the sender as the first signer (I sign first), then the Recipient Order values will be functionally pushed down the stack.
1 will be treated like 2, and only permitted access to the signer2 fields.
2 will be treated like 3, and so on.
In-Person Signing – Used when you expect the recipient to be in the same physical location as the sender, and want to permit in-person signing, hosted on the Sender's system.
This method escapes the default email verification process, so it is strongly recommended that you require additional non-trivial information to be gathered within the form (e.g. Drivers License, Social Security Number, etc.) to ensure a reasonable tie to the unique individual
Signing Order Required – This option dictates the core agreement flow.
- When True, a sequential signature process is followed, with one recipient at a time able to access the agreement. Each recipient will be notified once it is their turn to interact with the agreement, but not until it is their turn
- When False, a parallel signature process is followed, where all recipients are notified at the same time, and signatures/acceptance can be applied in any order
Post-Signing landing page URL – A public URL that you would like your signers to be routed to once they have applied their signature.
- If no value is provided, the standard post-signature page served by Adobe Sign is presented
Delay in Seconds for Redirect – If a Post-Signing landing page URL is provided, this field defines the number of seconds that the browser waits after the agreement is resolved before the redirect triggers and changes the browser to the landing page URL
Identity Verification – This setting defines the default verification method for all recipients attached to the agreement.
- This applies particularly to agreements that import recipients without using the AddRecipient activity:
- When Sender Signing Options is set to I sign first, I
sign last, or Only I sign - When Add Primary Email from Parent Entity is true
- When Sender Signing Options is set to I sign first, I
- Recipients added through a subsequent AddRecipient activity have the option to override the default identity verification method
All recipients are verified, at least by authentication to the email address that the agreement is sent to.
Second-factor authentication is available in several forms:
- Email – The default validation type. Employed for every recipient
- Phone – Second-factor verification that sends an SMS message to the recipient when they attempt to access the agreement.
- The recipient phone number and country code must be supplied in the Recipient Phone field and the Recipient Country Code field on the AddRecipient object
- Password – Second-factor verification that employs a standard alphanumeric password string
- The password must be communicated to the recipient through some external method
- Knowledge Base – Second-factor verification for recipients in the United States only.
- Uses non-trivial data mined from public databases to ask a series of personal questions
- Web Identity – Second-factor verification that uses successful authentication to one of several social media sites
- Valid sites for authentication include: Facebook, LinkedIn, Google, Yahoo!, Microsoft Live or Twitter
Set Password for Identity Verification – The password string to be used if Password verification is selected
Add Primary Email of Parent Entity as Recipient – When True, the process imports the email address of the primary entity as the first signer in the signature process
注意：
Add Primary Email of Parent Entity as Recipient directly impact the signature order of the agreement, and overrides the Recipient Order value as defined in the AddRecipient activities.
If you have defined a recipient with a Recipient Order value of 1, and then configure the CreateAccount activity to Add Primary Email of Parent Entity as Recipient, then the Recipient Order values will be functionally pushed down the stack.
1 will be treated like 2, and only permitted access to the signer2 fields.
2 will be treated like 3, and so on.
Schedule Recipient Reminders – Defines the reminder schedule for the agreement. Three options are possible:
- Never – No reminders are scheduled. Reminders can still be sent on-demand from the Agreement object in Dynamics
- Every day, until signed – A reminder email is sent every day until the Agreement is signed
- Ten iterations are observed. After 10 days, the reminder expires
- Every week, until signed – A reminder email is sent once every seven days until the Agreement is signed
- Seven iterations are observed. After sixty days, the reminder expires
The fields:
Agreement ID Input – Import the Agreement ID from the CreateAgreement activity
Add Documents from – Defines the source of the document. Documents are always picked up from the Notes of the target object. There are two options:
- Primary Entity Notes – The document is picked up from the Notes field of the primary Entity
e.g.: If you attach sales quotes to Opportunities, your workflow could be configured to use the Opportunity as the primary Entity.
When the workflow is triggered, the process will go to the opportunity to pick up the file(s) attached to the Opportunity Notes, where the Quote would be attached
- Process Notes – The documents are picked up from the Notes field of a Process instead of an Entity
e.g.: If you have a packet of standard new hire documents. These are standard boilerplate documents and it would make no sense to attach unique copies of the blank documents to every new User that you hire. Attaching the documents from the Process allows Admin control over the versioning process, and effectively makes the current version of the documents available to anyone that needs to trigger the workflow.
Select Process – Only meaningful when you select Add Documents from Process Notes.
This setting identifies the Process from which the document file(s) are retrieved
Document Name – Any given Entity or Process can have more than one file attached to the Notes field.
By supplying a Document Name, you ensure that the process only picks up the files(s) that match the named file.
If no Document Name is provided, all files will be picked up.
Add only the Latest Version of the Document – Frequently, documents will go through a versioning process. Contracts, for example, might have several iterations as the terms are negotiated. By setting Add only the Latest Version of the Document to True, only the most current version of the document (based on the attachment time/date stamp) is picked up when the documents are retrieved.
If the setting is False, all versions of the document(s) will be retrieved.
註解：
When creating a Global process (no primary Entity identified), remember that your document must be retrieved from the Process Notes.
The fields:
Agreement ID Input – Import the Agreement ID from the CreateAgreement activity
Recipient Full Name – An optional field that inserts the field value into email templates that otherwise would show the Recipient Email Address value
Recipient Email Address – The literal email address of the recipient. This value is used to deliver the document and associate the recipient with the agreement
Recipient Role – What is the recipient expected to do regarding the document:
- Signer – Someone that needs to apply a legal signature
- Approver – Recipients that only need to approve the document, but not necessarily sign it
- CC – CC’d recipients have no ability to influence the agreement, they are only observers of the process, and typically will get a copy of the agreement (depending on your Adobe Sign settings)
Recipient Order – This value represents:
- Where in the signature cycle the recipient resides when the signature process describes a sequential signature path. Entering a 1 indicates the recipient is the first recipient to gain access to the agreement
- Which fields the recipient has access to during the signature process. Fields on a document are identified by “signer” number. Entering a 1 indicates that the recipient should have access to the form fields designated for “anyone” and “signer1”
In a sequential workflow, recipient 2 is notified of the agreement only after recipient 1 has completed their part, and not before.
Recipient 2 is given access only to the fields designated for “anyone” and “signer2”.
Note for CC recipients: For the sake of clarity, all CC'd recipients should be assigned the Recipient Order that follows the last recipient to actually interact with the agreement. If you have three recipients as part of the signature cycle, CC'd recipients should be Recipient Order 4
註解：
Pay close attention to the Recipient Order, and be aware that the CreateAgreement activity can insert recipients into the front of the recipient list.
The settings that insert recipients are:
- Sender Signing Options: I Sign First - If Sender Signing Options is configured to I sign first, then the sender of the agreement will be the first recipient. Always.
- Add Primary Email of Parent Entity - When the email of the primary Entity is added through the CreateAgreement activity, this email is inserted as the first recipient.
- Only the Sender Signing Option (above) can insert a recipient before the parent entity primary email.
Override Default Verification - Allows the recipient to be assigned a different verification method from the default value defined in the CreateAgreement activity
- False - When false, the default Identity Verification method defined in the CreateAgreement activity is applied to this recipient
- True - When true, this recipient will have the Identity Verification method defined in this AddRecipient activity applied (see below)
Identity Verification – All recipients are verified, at least by authentication to the email address that the agreement is sent to. Second-factor authentication is available in several forms:
- Email – The default validation type. Employed for every recipient
- Phone – Second-factor verification that sends an SMS message to the recipient when they attempt to access the agreement.
- The recipient phone number and country code must be supplied in the Recipient Phone field and the Recipient Country Code field below
- Password – Second-factor verification that employs a standard alphanumeric password string
- The password must be communicated to the recipient through some external method
- Knowledge Base – Second-factor verification for recipients in the United States only.
- Uses non-trivial data mined from public databases to ask a series of personal questions
- Web Identity – Second-factor verification that uses successful authentication to one of several social media sites
- Valid sites for authentication include: Facebook, LinkedIn, Google, Yahoo!, Microsoft Live or Twitter
Note for CC recipients: All CC'd recipients should have their Identity Verification left as the default EMAIL value
Recipient Phone – The phone number to be used for the SMS phone verification process
Recipient Country Code – The country code that prepends the phone number for SMS verification
Recipient Password – The password string to be used if Password verification is selected
The fields:
Agreement ID Input – Import the Agreement ID from the CreateAgreement activity
Select the type of Recipient to be added – This field defines the type of Entity that you want to lookup when you identify the recipient. The options are:
- Lead
- Contact
- User
Add a Lead as Recipient – Allows you to map a Lead object into the signature cycle when Lead is chosen in the Select the type of Recipient to be added field
Add a Contact as Recipient – Allows you to map a Contact object into the signature cycle when Contact is chosen in the Select the type of Recipient to be added field
Add a User as Recipient – Allows you to map a User object into the signature cycle when User is chosen in the Select the type of Recipient to be added field
Be aware that when adding recipients using the above fields, you can search the system using a lookup, or you can select the recipient through the related entities of the parent entity.
Recipient Role – What is the recipient expected to do regarding the document:
- Signer – Someone that needs to apply a legal signature
- Approver – Recipients that only need to approve the document, but not necessarily sign it
- CC – CC’d recipients have no ability to influence the agreement, they are only observers of the process, and typically will get a copy of the agreement (depending on your Adobe Sign settings)
Recipient Order – This value represents where in the signature cycle the recipient resides when the signature process describes a sequential signature path. Entering a 1 indicates the recipient is the first recipient to gain access to the agreement.
Recipient 2 is notified of the agreement only after recipient 1 has completed their part, and so on.
Note for CC recipients: For the sake of clarity, all CC'd recipients should be assigned the Recipient Order that follows the last recipient to actually interact with the agreement. If you have three recipients as part of the signature cycle, CC'd recipients should be Recipient Order 4
註解：
Pay close attention to the Recipient Order, and be aware that the CreateAgreement activity can insert recipients into the front of the recipient list.
The settings that insert recipients are:
- Sender Signing Options: I Sign First - If Sender Signing Options is configured to I sign first, then the sender of the agreement will be the first recipient. Always.
- Add Primary Email of Parent Entity - When the email of the primary Entity is added through the CreateAgreement activity, this email is inserted as the first recipient.
- Only the Sender Signing Option (above) can insert a recipient before the parent entity primary email.
Override Default Verification - Allows the recipient to be assigned a different verification method from the default value defined in the CreateAgreement activity
- False - When false, the default Identity Verification method defined in the CreateAgreementactivity is applied to this recipient
- True - When true, this recipient will have the Identity Verification method defined in this AddRecipient activity applied (see below)
Identity Verification – All recipients are verified, at least by authentication to the email address that the agreement is sent to. Second-factor authentication is available in several forms:
- Email – The default validation type. Employed for every recipient
- Phone – Second-factor verification that sends an SMS message to the recipient when they attempt to access the agreement.
- The recipient phone number and country code must be supplied in the Recipient Phone field and the Recipient Country Code field below
- Password – Second-factor verification that employs a standard alphanumeric password string
- The password must be communicated to the recipient through some external method
- Knowledge Base – Second-factor verification for recipients in the United States only.
- Uses non-trivial data mined from public databases to ask a series of personal questions
- Web Identity – Second-factor verification that uses successful authentication to one of several social media sites
- Valid sites for authentication include: Facebook, LinkedIn, Google, Yahoo!, Microsoft Live or Twitter
Note for CC recipients: All CC'd recipients should have their Identity Verification left as the default EMAIL value
Recipient Phone – The phone number to be used for the SMS phone verification process
Recipient Country Code – The country code that prepends the phone number for SMS verification
Recipient Password – The password string to be used if Password verification is selected
Actions are a type of Process that link activities together to achieve some product, but they are not directly available to users.
Instead, they can be thought of as re-usable modules that can be included in Workflows. A few carefully created Actions can be included in a wide range of diverse Workflows, without having to re-configure these common steps.
Two pre-configured Actions are available and ready for use.
These are simple, broadly used processes that you may be able to leverage in creating your own custom workflows:
This Action is a simple, generic action to send an agreement to one recipient for electronic signature.
At the top of the properties page, you can see that:
- There is no Entity tied to this Process
- This makes the Action available
to any type of Workflow - Because there is no primary Entity, the file must be retrieved from the Process
- This makes the Action available
There are four activities in the process chain:
- CreateAgreement
- The agreement name and message are generic. Applicable to just about anything
- ESIGN is the signature type, a good default
- The sender is not required to sign
- A sequential signature order is applied
- Email verification is selected. No second-factor verification
- No Reminder schedule is configured
- AddRecipient
- The Agreement ID is imported from CreateAgreement
- The recipient email is being inserted from the Arguments object
- The recipient is identified as number 1 in the signature
process, and is a Signer, so a signature is required
- AddDocument
- The Agreement ID is imported from CreateAgreement
- The file is being retrieved from the Process Notes
- The process that holds the correct file is the Send for
Signature process (this same process) - The process will send all versions of all files that are attached to the Notes section of the process
- No Document Name is provided, so all uniquely named files will be attached
- Add Only the Latest Version is set to False, so all versions will be included
This Process is a simple, generic action to send an agreement to one recipient for electronic signature.
At the top of the properties page, you can see that:
- The primary Entity is the Opportunity
There are four activities in the process chain:
- CreateAgreement
- The agreement name and message are generic. Applicable to just about anything
- ESIGN is the signature type, a good default
- The sender is not required to sign
- A sequential signature order is applied
- Email verification is selected. No second-factor verification
- No Reminder schedule is configured
- AddRecipient
- The Agreement ID is imported from CreateAgreement
- The recipient email is being inserted from the Contact object
- The recipient is identified as number 1 in the signature
process, and is a Signer, so a signature is required
- AddDocument
- The Agreement ID is imported from CreateAgreement
- The file is being retrieved from the primary Entity
- The process will send all versions of all files that are attached to the Notes section of the primary Entity
- No Document Name is provided, so all uniquely named files will be attached
- Add Only the Latest Version is set to False, so all versions will be included
Workflows are a type of Process that can be executed by the system or on-demand by users.
Workflows typically are created with one or more Actions, Conditions, or Activities.
Workflows can respond to field level changes or be initiated by users through the More Options (...) menu on each Entity, depending on how they are configured.
The Adobe Sign for MS Dynamics CRM v7 package has one pre-configured workflow in a Draft status. this workflow is designed with Activities to illustrate the structure, but could just as easily been created with the one Conditional trigger event, and one Action that contained the Activities:
At the top of the properties page, you can see that:
- The primary Entity is the Opportunity
- The workflow is designed to allow on-demand access
In the Process builder section, the first line item is a condition that can trigger the workflow:
If the Opportunity Status is changed to Won, then execute a series of steps.
There are four activities in the process chain:
- CreateAgreement
- The Agreement Name is being inserted from the Opportunity
- The agreement message is generic
- ESIGN is the signature type
- The sender is not required to sign
- A sequential signature order is applied
- Email verification is selected. No second-factor verification
- No Reminder schedule is configured
- AddRecipientUsingLookup
- The Agreement ID is imported from CreateAgreement
- The recipient is identified as a Contact
- The recipient email is being inserted from the Contact field on the Opportunity object
- The recipient is identified as number 1 in the signature
process, and is a Signer, so a signature is required
- AddDocument
- The Agreement ID is imported from CreateAgreement
- The file is being retrieved from the primary Entity
- The process will send all versions of all files that are attached to the Notes section of the primary Entity
- No Document Name is provided, so all uniquely named files will be attached
- Add Only the Latest Version is set to False, so all versions will be included
Below is an example of how you can build a simple process to send a Non-Disclosure Agreement (NDA) contract to a Contact in the Dynamics system.
For the purpose of this example, there are some givens that provide a framework for making workflow decisions:
- Anyone that would be sent an NDA would exist as a Contact in the Dynamics system
- The NDA document is version
controlled, and is attached through the Process Notes, not the Entity - The owner of the Contact must counter-sign the contract
- The contract must be sent to an email archive file
If you are new to the idea of passing the output from one activity to serve as the input values for a subsequent activity, it may be worth your time to review the process.
Activities are designed to accept input values from trigger events or other activities, and then make new values available to subsequent activities in the process.
In the below image the Agreement Id Input field needs to have the ID value imported from the CreateAgreement activity.
To import the output of a previous activity, you will need to link the object path to the field where you need the value:
- Single click the field you need to import the value into.
- The Look
for: picklist populates with the objects related to the primary Entity as well as Local Values from the process
- The Look
- Click on the picklist to expand it
- The value we are looking for was generated in a previous Activity, making it a Local Value, which is populated at the bottom of the list
- Select the AdobeSign
:Activities .CreateAgreement object
The list collapses showing the selected object as the Look
The list immediately under the Look
CreateAgreement only has one output value: Agreement ID Output
- Select the correct output value, and click the Add button to insert the value into the selectable values section just below
- When you see the Agreement ID Output in the selectable values section, click OK to insert that value into the field
To build the process:
- Navigate to Adobe Sign Admin > Create New Workflow
- A new Create Process overlay opens
- Give the process an intuitive name. The name of the process is only seen by Administrators
- Select Action from the Category picklist
- Select the primary Entity from the Entity picklist
- Any Entity in Dynamics can be
selected, and provides the objects that the process can use in the workflow - None (global) is an option for workflows that are not tied to Entities
- Any Entity in Dynamics can be
This example presumes that anyone sent an NDA will be a Contact, so we use Contact as the primary Entity.
- Click OK
- A PowerApps page opens, displaying the Process Information page
The step-by-step process is built at the bottom of the page. Scroll down to the Add Step section
- Click Add Step
- Scroll down to the Adobe Sign picklist item, and expand the sub-menu
- The six Actions for Adobe Sign are exposed:
- AdobeSign.Activities.AddDocument
- AdobeSign.Activities.AddRecipient
- AdobeSign.Activities.AddRecipientUsingLookup
- AdobeSign.Activities.CreateAgreement
- AdobeSign.Activities.CreateAgreementFromTemplate
- AdobeSign.Activities.SendAgreement
- The six Actions for Adobe Sign are exposed:
The full process to get a document signed includes at least three of these in roughly this order:
Create an Agreement – The “Agreement” is the container object that holds all the configuration values for the full transaction through the Adobe Sign system.
There are two options when creating the Agreement
- Create Agreement from Template – Uses an Agreement Template that must already be defined, importing all the field value
- Create Agreement – Provide the Agreement field level values for just this process
Add Document – This attaches the file (or files) to be sent
- There is a 5MB limit to the size of
file you can upload to Dynamics - Documents are added
through the Notes field on either the primaryEntity , or the Process, depending on your needs- Documents attached to primary Entities tend to be custom documents, like an individualized contract that would be attached to an Opportunity
- Documents attached to a process could be version-controlled boilerplate documents, like a non-disclosure agreement
註解：
It’s possible to add the Recipients before the Document.
Linear thinking suggests that adding the document first improves understanding of the process because, in most cases, the type of document indicates who the recipients are, and in what order they should be involved in the signature process.
Add Recipient – Recipients are the people that are included in the
- Signers – Anyone that needs to apply a legal signature
- Approvers – Recipients that only need to approve the document, but not necessarily sign it
- CCs – Purely observers, CC’d recipients have no ability to influence the agreement
- A great option for automatically archiving a type of document to an email address
There are two options for adding recipients:
- Add Recipient Using Lookup – Leverages Dynamics to import a recipient email from a Dynamics Entity
- Add Recipient – Allows for a recipient to be included that is not associated with any Dynamics Entity by explicitly configuring the email
註解：
There are two ways to create a process where no AddRecipient activity would be required:
- The sole recipient is imported as the primary email from the parent Entity on the CreateAgreement activity
- The sole recipient is the signer using the Only I sign option in the Sender Signing Options field on the CreateAgreement activity
Send Agreement – The activity that takes the configured Agreement and submits it to the Adobe Sign service, starting the signature process
Our NDA example uses five of the six Activities (there can be only one “Create Agreement” type of activity), in a five-step process:
1. Add Step - AdobeSign.Activities.CreateAgreement
- Click Set Properties in the step record to open the activity properties
- Define the Agreement Name – The Agreement Name displays in the notification emails to your recipients and represents the agreement throughout the Dynamics system. Use an intuitive name that indicates the nature of the document your recipients are expecting
- Click Save and Close when done
Field values for this example:
- The Agreement Message was altered to provide meaningful instructions in regard to the document attached
- An expiration value of 5 was inserted to ensure this legal document isn’t left open for an unacceptable span of time
- The agreement will expire and auto-cancel after 5 calendar days
- The Primary Email of the Parent Entity will be imported as the first recipient
- A reminder is scheduled for Daily iteration (given the agreement expires in five days)
註解：
As you successfully configure the activities, the red X is removed from the step records
2. Add Step – AdobeSign.Activities.AddDocument
- Click Set Properties in the step record to open the activity properties
- Insert the Agreement ID value into the Agreement Id Input field
- Define the Add Documents from field
- Define the Select Process field if attaching the file from a Process
- Configure any other fields needed
- Click Save and Close
Field values for this example:
- The Add Documents from
field is configured to retrieve the NDA file from the Process Notes - Select Process – Because we are retrieving the file from a Process, we need to indicate which Process contains the file
- This example lookup refers to the same Process we are currently developing
- Document Name is left blank – Because the focus of this Process is very narrow, only pertaining to NDA contracts, there is no expectation that anything other than the NDA file will be attached to the Process
- Add only the Latest Version of the Document is configured to True. If there are iterating versions of the NDA, we don’t want to send all the versions, just the most recent
3. Add Step - AdobeSign.Activities.AddRecipientUsingLookup (User)
- Click Set Properties in the step record to open the activity properties
- Insert the Agreement ID value into the Agreement Id Input field
- Because this is adding a recipient by lookup, define the Entity that identifies your recipient: Lead, Contact or User
- Define the Recipient Role – Is this recipient a Signer, Approver, or CC
- Define the Recipient Order – As this is the second recipient, enter 2
- Because the CreateAgreement activity is configured to Add Primary Email from Parent Entity as the first recipient
- Define the Identity Verification – Email is the default. If you want to add second-factor verification, adjust the field accordingly
- Configure any other fields needed
- Click Save and Close
Field values for this example:
- Because this is the second recipient, the User Entity type is selected. Internal counter-signatures typically take place after the external recipient has applied their signature
- Add a User as a recipient is configured to lookup the User
- The default Signer is left in place as a signature is required
- 2 is entered in the Recipient Order field. The internal signer always follows the external signer
4. Add Step - AdobeSign.Activities.AddRecipient
- Click Set Properties in the step record to open the activity properties
- Insert the Agreement ID value into the Agreement Id Input field
- Provide the optional Recipient Full Name if there is one
- Add the Recipient Email Address
- Define the Recipient Role – Is this recipient a Signer, Approver, or CC
- Define the Recipient Order – As this is the third recipient, enter 3
- Configure any other fields needed
- Click Save and Close
Field values for this example:
- This recipient is the CC to our internal NDA archive email address
- Instead of a person’s name, an appropriate description is inserted into the Recipient Full Name field instead
- The full email address is added
- The CC option is selected as this recipient is just collecting our signed
NDAs for backup record keeping - 3 is entered in the Recipient Order field. The recipient isn’t technically in the signature cycle, but the field is required
- CC recipients should always be listed after the recipients that participate in the signature/approval process
5. Add Step - AdobeSign.Activities.SendAgreement
- Click Set Properties in the step record to open the activity properties
- Insert the Agreement ID value into the Agreement Id Input field
- Click Save and Close
Once the steps are all configured:
- Scroll to the top of the page, and click the Notes tab.
- With the Notes tab open, click in the field where it says Enter a note
- The tab content changes again to expose an Attach File button
- Click Attach File
A new pop-up is generated with a Browse button so you can search for your file and attach it.
- Click Browse...
- Locate your file and Open it
- This imports the file path to the File Name field and closes the Browse... window
- Click the Attach button
- Click the Close button
With the file attached to the Notes section of the Process, all that is left is to activate the Process.
- Click the Activate button at the top of the window
If there are no errors, the page will refresh, showing the Deactivate button at the top of the page (replacing the Activate button)
The Action is complete.
To make it available to users, you need to tie it to a Workflow:
- Click the Close button in the upper-left of the window to close the PowerApp page
- Return to the Adobe Sign Admin page, and click Create New Workflow again
- The Create Process overlay opens
- Select Workflow from the Category picklist
- Select the same primary Entity from the Entity picklist that you selected for the process
- This is the Entity where the senders can find the workflow listed
- Click OK
The Process Information page loads.
Because this example is for an NDA contract, we want to enable it as an on-demand option.
- Check the box next to As an on-demand process
- Click the Add Step button in the process builder
- Select Perform Action from the list of options
- In the Action field, select the process that was just created
- The Entity field auto-populates based on the selected process
- Click Set Properties in the step record to open the activity properties
- Configure the Target setting
- Click Save and Close
- Once the steps are all configured, scroll to the top of the page, and click Activate
- Click Activate again when challenged
The Workflow is
Test the Workflow:
- Navigate to any Contact
- Click the More Options list in the ribbon (…)
- Click Run Workflow
A list of workflows related to the Entity displays
- Check the box next to the workflow you want to trigger
- Click Add at the bottom of the panel to start the workflow
A Hybrid Signature Routing is a combination of a sequential signature process that has one or more stages where the signature process becomes parallel.
More than any other type of signature flow, hybrid routing demands a strong understanding of the
Field assignment (signer1, signer2, etc) is predicated on the order that the recipients are listed in the process or UI. Within a parallel signature stage, all of the recipients have the same Recipient Order number, so the physical placement in the process/UI is your only queue as to which form field the recipient has access to.
The topmost recipient in the process/UI is signer1.
The second listed recipient in the process/UI is signer2, even if the signature flow is parallel and both recipients indicate a recipient order of 1.
- Hybrid routing only works if it's enabled in the Adobe Sign account
- Log in to Adobe Sign as an account admin
- Navigate to Account > Send Settings > Signing Order > Allow senders to specify hybrid routing order
- Save the setting
- Agreement Templates
can not be configured to leverage hybrid routing - Hybrid routing is not supported when the Signature Type is Written
- Hybrid routing does not support a process where the Sender Signing Order is
- I sign first
- I sign last
- Only I sign
- Including the Primary Email from the Parent Entity, identifies the recipient with a Recipient Order of 1. If there are other recipients with a Recipient Order of 1, then hybrid rules are applied
- If a process is defined where Order Entered = False (indicating a parallel signature flow), but the recipients do not all have the same Recipient Order value (indicating a sequential signature flow), then hybrid routing rules apply.
Sometimes a process that shows no error in configuration will fail during runtime.
The commonly identified reasons that can happen are:
- There is no file attached to the Note section that you are attempting to fetch the file from
- The Identity Verification method, as defined in the AddRecipient or CreateAgreement Activity, is disallowed by the settings in your Adobe Sign account
- There is no Contact on the primary Entity, and your CreateAgreement activity has Add Primary Email of Parent Entity as Recipient set to True
下載
