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 user, or configured to trigger when defined events occur.
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:
Previous version of Dynamics (2011/2013/2016) are not supported by version 7 of the Adobe Sign package.
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:
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:
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.
Post-Signing landing page URL – A public URL that you would like your signers to be routed to once they have applied their signature.
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.
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:
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:
The field:
Select an Agreement Template – A Lookup field that presents the available Adobe Sign templates that you can use to generate an agreement
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:
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
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:
Recipient Order – This value represents:
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:
Override Default Verification - Allows the recipient to be assigned a different verification method from the default value defined in the CreateAgreement activity
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:
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:
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:
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:
Override Default Verification - Allows the recipient to be assigned a different verification method from the default value defined in the CreateAgreement activity
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:
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 field:
Agreement ID Input – Import the Agreement ID from the CreateAgreement activity
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 are four activities in the process chain:
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:
There are four activities in the process chain:
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:
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:
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:
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:
The list collapses showing the selected object as the Look for: value
The list immediately under the Look for: field provides all the possible output values for the selected object.
CreateAgreement only has one output value: Agreement ID Output
To build the process:
This example presumes that anyone sent an NDA will be a Contact, so we use Contact as the primary Entity.
The step-by-step process is built at the bottom of the page. Scroll down to the Add Step section
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
Add Document – This attaches the file (or files) to be sent
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 completion path for the Agreement. They can include:
There are two options for adding recipients:
There are two ways to create a process where no AddRecipient activity would be required:
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
Field values for this example:
As you successfully configure the activities, the red X is removed from the step records
2. Add Step – AdobeSign.Activities.AddDocument
Field values for this example:
3. Add Step - AdobeSign.Activities.AddRecipientUsingLookup (User)
Field values for this example:
4. Add Step - AdobeSign.Activities.AddRecipient
Field values for this example:
5. Add Step - AdobeSign.Activities.SendAgreement
Once the steps are all configured:
A new pop-up is generated with a Browse button so you can search for your file and attach it.
The file is now properly attached to the Process Notes
With the file attached to the Notes section of the Process, all that is left is to activate the Process.
When the activation challenge pops up, click Activate
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:
The Process Information page loads.
Because this example is for an NDA contract, we want to enable it as an on-demand option.
The Workflow is complete, and related to the primary Entity (Contact in this example).
Test the Workflow:
A list of workflows related to the Entity displays
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 form, and the order that the signatures are expected to be applied.
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.
Sometimes a process that shows no error in configuration will fail during runtime.
The commonly identified reasons that can happen are:
下載
登入您的帳戶