My Inbox is a widely used Fiori application for all kinds of approval tasks ranging from Purchasing documents, Invoices to Leave requests and Timesheets. My Outbox lists all the Completed and Suspended tasks from Inbox. These are important applications from a wide variety of perspectives like single-entry point for all approval tasks and daily usage by Business Executives among many others.
There are certain features which make these apps the best suitable for approval tasks. But based on my experience most clients like to tweak the functionality to satisfy certain business needs.
We will discuss one such scenario today.
Problem – Suspend in conflict with Deadline Monitoring
The unique problem that we faced with one of our clients was that, we were using a custom workflow for Purchase Requisitions and using the Deadline Monitoring feature of workflow. By business definition, the deadline time was maintained as a TVARVC entry and was set to 48 hours. Users would get a task in their Inbox. If they did not take an action (Approve/Reject) within 48 hours, then it would be escalated to a Secondary Approver.
The problem started when Users anticipated that 48 hours were not enough to take a decision on a specific task and hit the ‘Suspend’ button. They expected that the task would be back in their Inbox after the stipulated time of Suspension. This DID NOT HAPPEN!
Suspension of a task DID NOT reset the Deadline clock!
This was a huge gap, since Users would suspend a task for more than 48 hours and it would directly get escalated to Secondary Approver without the Initial Users’ knowledge or intimation.
Solution – Implemented Program Exit in Workflow task, captured the Suspend Event and reset Deadline clock
We took help from the Program Exit Feature of a workflow task. This can capture any event on a task. There are specific callback function modules that get called based on User actions on My Inbox like Suspend/Resume, Forward, Claim/Release, etc. We utilized these to capture the moment when User Suspended a task and reset the Deadline Clock on the task. Voila! No conflicts. When user gets the task back in My Inbox (after Suspension period is over) he gets a fresh 48 hours to work on it before it is escalated.
Placing the Workflow Exit in the Inbox task step
Creating the Custom Program exit class
Capturing the events using the interface IF_SWF_IFS_WORKITEM_EXIT
Capturing runtime data using CL_SWF_WIM_FACTORY
Selecting the user action when Suspended
Getting the current deadline details
Setting the LE(Latest End) and DS(Desired Start) deadline times
Well, this helped in resolving the Deadline conflict issue.
But of course! This was not the end of all problems.
User could go on a loop of subsequent Suspends and receiving back task in Inbox. So, business decided that we restrict it to Suspension once on each task.
Also, a maximum number of business days that a work item could be Suspended.
**Suspended days = (suspension end date – today’s date) – holidays
And again, if User decided to work upon it before the Suspension period was over. He should be able to get in My Outbox and ‘Resume’ the task to get it back in My Inbox. The deadline clock must be reset from the moment task is back in My Inbox.
This satisfied all the requirements and resulted in quite a robust solution.
Other events can be captured as follows –
There were some issues to send relevant error messages to front end where we worked with SAP to resolve and the following note was published in the course.
2864501 – “RFC Error: Runtime error occurred in backend system” – generic message
This solution was designed and implemented in SAP S/4 HANA 1809 On-Premise system.
Hope this solution helps!
Please provide your valuable feedback and insights.
Refer below links for extensibility of My Inbox –
