Inbound Email Response not updating target record - OOTB 'Inbound Email Action'?

henrikloman
Giga Contributor

Hi Community,

We are using the OOTB Notification that goes out to our Approver's as soon as a Service Catalog Request is created in the system.

The Notification gives the Approver the option to 'Approve' / 'Reject' the Request via the Notification response.

Issue: This functionality is currently not working as despite responding 'Reject' in the Notification the actual 'Request' status do not change.

I can confirm that we recieve and process the inbout message BUT it does not seem to trigger any 'Inbound Email Action' to update the target Request status.

Question:

Does anyone know what the OOTB 'Inbound Email Action' is called for Catalog Request  functionality, and if not then how would you set one up if you had to do it from scratch?

find_real_file.png

Thanks,
Henrik

1 ACCEPTED SOLUTION

Yes! The account listed in the approval is the person it's looking for to change the state.

View solution in original post

5 REPLIES 5

Michael Fry1
Kilo Patron

There is just 1 inbound action that handle approvals/rejections - Update Approval Request. It's on the approval table, not specific to catalog request, change, etc

There is also a business rule named - SNC - Run parent workflows (Approval) - with condition that contains: current.state.changesTo('rejected') - is this rule active?

henrikloman
Giga Contributor

Hi Michael,

Thank you for pointing me in the right direction as appreciated:),

Found the Inbound Action: 'Update Approval Request' and when looking at the email log entry for the incoming response again I can see that it stops against that particular rule so guess it met the conditions BUT can't see any action on the actual record. I have attached the Script for this Inbound Action in case the issue is in the script itself?

find_real_file.png

I have checked the BR (SNC - Run parent workflows (Approval) you mentioned and can confirm that it is active and trigger on 'After' (Insert/Update/Delete).

current.state.changesTo('approved') || current.state.changesTo('rejected') || current.operation() == 'delete'

// Run any workflows for our parent so they can check the approval states
//
// 3.20.2011 - modified to use generic approval for any table via the document id/source_table,
// the check for sysapproval remains to provide backwards compatibility for records already in
// play that were entered into approval using the sysapproval to store taskID.
// Going forward, all records will get a document_id and a source table, but if they are null, this
// function assumes sysapproval column in the task table.

runWorkflow_userApprove();

function runWorkflow_userApprove() {
var id = current.sysapproval.nil() ? current.document_id : current.getValue('sysapproval');
var table = current.source_table.nil() ? 'task' : current.source_table;
if (id != null && table != null ) {
var gr = new GlideRecord(table);
if (gr.get(id)) {
new Workflow().broadcastEventToCurrentsContexts(gr, 'update', null);
}
}
}

If you can see or think of anything obvious then let me know:)

Cheers,

Henrik

 

henrikloman
Giga Contributor

Had a thought, could it be that I am responing from my test account and that due to not coming from the 'Approver' registered User Profile email validation stops update from happening?

In other words, maybe it works if respond from Approver = Joanna's address instead of mine?

find_real_file.png

Yes! The account listed in the approval is the person it's looking for to change the state.