Contract rejection email do not capture the data of the contract record

[Abhinab Achary1]

Hello All, 

I have a requirement as below for contract management

1. When a contract approval is 'Rejected', it should send a notification to the created by user of the record , with all the details of contract such as Vendor, Customer etc from contract field in the form. 

What I have implemented is :

1. In the workflow: Contract Approval

> Created an event called contract.requestor.rejected

> Created an event activity in the approval workflow, this should trigger the event.

>Created a notification: This will accept the 'Parm2' as recipient(usd gliderecord to fetch the created by)

> In the body, I have added the contract details where, I used the document_id of the approval to fetch all the details of the contract. eg. ${document_id.number} .....etc

How it is working now?

Now an email gets triggered to the correct recipients(that is happening via the event Parm2), but its missing all the information that is supposed to be in the actual email like the details of the contract record.

Why is this not fetching the details and how can this be fixed?

[Mark Manders]

Why not use the flow designer for this? The 'send notification' action has everything you need, because you can just drag and drop all information you need.

[Abhinab Achary1]

yeah this flow of contract approval is OOTB defined in a 'Workflow' and so I thought these changes if can be done in the same place to avoid confusion. Otherwise I need to write a complete flow for contract and disable to OOTB workflow(this becomes customization in my opinion). What do you think is the right way ?

Additioanlly this requirement now has two approvals, after which its gets fully Approved. So if we write a flow that is based on the field 'Substate', it will be difficult to identify which of the two approvals got rejected without write hefty codes

[Mark Manders]

You can get the 'reject' notification out of the workflow and put it into a flow, based on the rejection. The rest stays the same. However: changing the OOB workflow is customization as well, so no matter what you choose to do, it will be customization. If customizing is something you don't want to do, you have to return the requirement with the message that it's not OOB, so won't be done.