Oracle HCM Journeys to capture Multiple E-Signatures with Native E-Sign Task
The Native E-Signature (E-Sign) feature in Oracle Journeys enables employees to read and electronically sign documents, storing the signed documents in their records for future reference. For example, you may require employees to sign a confidentiality agreement and save it in DOR. However, a single native electronic signature task cannot accommodate multiple signatories, such as both an employee and a manager. Instead, you can create a series of dependent native electronic signature tasks, each with its own required signatories, and generate a custom electronic signature BIP report that progressively captures details from previously completed tasks.
In this article, I will guide you to setup Journeys E-Sign tasks to capture employee and manager’s signatures on the same document. Detailed instructions on Configure Native Electronic Signature in Journeys are documented here. We are going to leverage this functionality and setup 2 E-Sign tasks for our specific usecase at hand.
Let’s first understand Data Model, RTF Template, Journey Integration and Checklist template required to make this work.
Datamodel
We use the parameters from the current task to derive the current & previous task signer details. Below are the steps
- The ‘AllocatedChecklistId’ & ‘AllocatedTaskId’ parameters is used to derive the current task and ‘SignName’, ‘SignDate’ and ‘SignerAddress’ parameters are used to derive the current task signer (Sign Confidentiality Agreement Level 2)
- The ‘per_allocated_tasks’. ‘dependent_on_tasks’ column is used to derive the preceding task (Sign Confidentiality Agreement) and signer details
- The current and previous task signer details are available to be printed in the report
Sample query:
/*Query block to derive the signer details of the preceding Esign task which is completed*/
(SELECT p_pac.allocated_checklist_id,
p_pat.allocated_task_id,
p_pac.person_id,
p_pat.signer_name,
p_pat.signer_email,
p_pat.sign_date,
p_pat.signer_address
FROM per_allocated_checklists p_pac,
per_allocated_tasks p_pat
WHERE 1=1
AND p_pac.allocated_checklist_id = p_pat.allocated_checklist_id
AND p_pac.allocated_checklist_id = :p_allocated_checklist_id
AND p_pat.action_type = ‘ORA_CHK_ESIGN’
AND p_pat.status = ‘COM’)
SELECT pac.person_id,
pat.allocated_checklist_id,
pat.allocated_task_id,
pat.task_initiator_person_id,
pat.dependent_on_tasks,
prior_task.allocated_task_id prior_allocated_task_id,
/*Condition to check and display the signature based on the task and performer*/
CASE
WHEN prior_task.allocated_task_id IS NULL THEN :P_SIGNER_NAME
ELSE prior_task.signer_name
END AS signer1_name,
CASE
WHEN prior_task.allocated_task_id IS NULL THEN :P_SIGNER_EMAIL
ELSE prior_task.signer_email
END AS signer1_email,
CASE
WHEN prior_task.allocated_task_id IS NULL THEN :P_SIGN_DATE
ELSE to_char(prior_task.sign_date)
END AS signer1_date,
CASE
WHEN prior_task.allocated_task_id IS NULL THEN :P_SIGNER_ADDRESS
ELSE prior_task.signer_address
END AS signer1_address,
CASE
WHEN prior_task.allocated_task_id IS NOT NULL THEN :P_SIGNER_NAME
ELSE NULL
END AS signer2_name,
CASE
WHEN prior_task.allocated_task_id IS NOT NULL THEN :P_SIGNER_EMAIL
ELSE NULL
END AS signer2_email,
CASE
WHEN prior_task.allocated_task_id IS NOT NULL THEN :P_SIGN_DATE
ELSE NULL
END AS signer2_date,
CASE
WHEN prior_task.allocated_task_id IS NOT NULL THEN :P_SIGNER_ADDRESS
ELSE NULL
END AS signer2_address
FROM per_allocated_checklists pac,
per_allocated_tasks pat,
prior_task prior_task
WHERE 1=1
AND pac.allocated_checklist_id = pat.allocated_checklist_id
AND pac.allocated_checklist_id = :p_allocated_checklist_id
AND pat.allocated_task_id = :p_allocated_task_id
AND pac.person_id = prior_task.person_id(+)
AND pat.dependent_on_tasks = prior_task.allocated_task_id(+) /*Condition to derive the preceding task*/
Note: The query needs to be modified to accommodate additional signatures for the same document.
RTF Template
The RTF Template displays the signature in the appropriate section based on the information derived from the above query. A sample tempate is attached with this blog, modify the template according to the business requirements.
Sample Template:
Journey Integration
The Journey Integration configuration has been improved in the 24B Fusion release to include a signature pad, enabling users to provide a physical signature when e-signing a document. However, the physical signature will not be saved as part of the journey task and will only appear in the PDF version of the document. Therefore, we will NOT be using the signature pad. The Journey Integration will be as follows:
Please note: A Signature Pad cannot be used in this setup for it to function properly.
Checklist Template
We will utilize the Journeys Integration to create two E-Sign tasks: one for the employee and another for the line manager. These tasks will be dependent, ensuring that the employee signs the document first, followed by the line manager signing the document completed by the employee. This setup only works if the second E-Sign task has a preceding E-Sign task configured.
Additionally, we won’t save the document to DOR immediately after the employee signs. Instead, we will configure DOR for the E-Sign task assigned to the line manager, ensuring that the document is saved in the DOR of the journey assignee when the manager marks the task as Done.
You can enjoy an enhanced user experience through the new Journey Templates page from 24D. The Redwood Journeys Templates page mirrors the existing Checklist Templates page, offering the same functionality, including validations. Here’s a preview of the Redwood Journey Templates page:
Now that the setup is complete, let’s assign journey to employee and see the user experience.
Employee Signs the Document
The employee will receive a notification for the journey task and can use their Display Name to sign the document. They can review the document in a pane before completing the task.
Line Manager Signs the Document
Once the employee marks the E-Sign task as complete, the dependent E-Sign task will become available to the manager. The manager can review the document signed by the employee and sign it as well. When the manager marks the task as Done, the document will be saved in DOR.
This is how you can enable both the employee and the line manager to sign the same document. Importantly, this setup is scalable. You will need to adjust the Data model, RTF and Journey templates according to your business requirements to accommodate additional signatures for the same document.
Hope this helps!