Signature workflow covers the process following obtaining formal approval that the contract can be signed, to executing the contract (i.e. having the contract signed by all parties).
- Are there different signees for different regions?
- Do some regions require a local signatory? In addition to a senior signatory or as a replacement signatory?
There are two aspects to cover from a design perspective:
- Who signs first?
- “Wet” signature vs Electronic signature
- Whether multiple signature workflows are required to comply for local laws
The first does not have a major impact. As a general rule of thumb, the party whose paper was used tends to be the party to sign last (as they initiate the signing process and would prefer the other party to sign first.) However, in CLMA it really doesn’t matter as long as the fully executed contract makes it way back into the system.
What has more of an impact is whether electronic signatures will be used. If electronic signatures form part of the solution (strongly recommended), then the signed contracts will automatically be uploaded back into CLMA, avoiding the step to scan and upload them manually.
The biggest factor however is whether different processes / signatories are required based on local laws. As an example, contracts might normally be signed by the CFO (who is based on country x), but in country y it needs to be signed by a citizen of that country before it is legally binding.
If this is a requirement and assuming the rules for determining when this applies can be “codified”, then the Contract Template can be used to determine whether one of more signature blocks needs adding to the contract document, in addition to whether one or more signatories per party is required. The integration with the e-signature vendor can handle multiple signatories, so it's more about ensuring that the relevant data is captured during the contract drafting stage.
For “Wet” signatures, this process needs to be managed operationally to ensure the correct signatures are collected.
- CLMA has native integration capabilities with both DocuSign and AdobeSign. If however the customer uses a different eSignature vendor, then contracts will need to be manually signed, scanned and uploaded.
- eSignature vendors have additional functionality which is not included within the CLMA integration. The customer may have seen or used some of this additional functionality with an expectation that those functions will be available with the CLMA eSignature integration.
Things to avoid
Avoid using the eSignature integration to obtain internal approval related signatures. The integration was not developed for this use case. Workflow tasks are used for Approval and it is possible to see who approved each workflow task. This is enough coverage from an auditing/reporting perspective.