- SAP Managed Tags:
Very recently I was asked to test Flexible workflows available on S/41709 with SAP Fiori 4.0 front end server. The scenario was one of our very favorites "Purchase Order Release".
If one would search my contributions on SCN, they'll understand why I mention favorite before PO release scenario. To be candid, as a developer while doing the customization for Release Strategy trigger and checking the approval process few years back, I had investigated the entire process so well that for any PO release scenario I'd usually start with the release strategy configuration.
So, when flexible workflow was thrown before me, my first approach was trying to find out how it's getting triggered, what is it and what is the configuration required for it. What is the use in first case when we've the wonderful Business workflows to cater to every possible scenario? The mind-set was to compare old Vs new and that only caused a lot of questions.
This reminded me of car learning experience in the US. I was trying to learn driving in the US by comparing it with the way I learnt driving in India, needless to mention the models of the car were different. My teacher said that you will not learn by comparison rather start afresh. Now someone should not consider this as a great pointer for their learning as the teacher also happens to be my spouse 😐
However, I applied the same principle with flexible workflows. One of the early learnings that I've gained is: the only documentation one could trust for SAP CP and S/4H latest is the SAP documentation. For the apps on S/4H, the documentation could be found on Fiori apps library.
This is really good and I find the quality of documentation to be good as well. The next step was to go to the app. I find using the search button to navigate to the required button is good enough.
The first intention was to create a workflow to test that it gets triggered. That was quite an effort. Workflow creation seems to be really very easy and fast and satisfies the points highlighted in documentation that business people could create without having to depend on IT team.
The first hurdle was Purchase order creation ending in failure. In such scenarios, the problem could be with gateway, UI or backend. Interestingly, I could find both a dump in the system and gateway errors. The gateway error log does not really provide accurate enough information to reach to the root cause of the issue. It provides a generic troubleshooting guide which could consume a lot of time without fixing the issue. Finally, I was shared the information that the problem was with the RFC destination and once it was fixed the purchase order was getting created. Thankfully, I had already checked the needed SPRO configuration to be done to trigger the flexible workflow. The WF got triggered and then I could jump to the questions related to Workflow. The first being multi-level approval.
The multi-level approval is very well supported and it could be controlled based on few conditions which are readily available. One of the most common scenarios being approvers being decided on the PO amount.
For every step there is a precondition:
What this would mean is, once all required approvals are done the PO is released and the same gets shown in the status tab of PO display. This is unlike my prior experience with release wherein release indicator would let us know if the PO is released. Additionally, a new tab is added in PO display screen for Flexible workflows. However, the data populated in the tab in different scenarios was not consistent enough to draw conclusion on its content.
Another interesting feature is multiple recipients could be added in the agent list and either all of them or one of them are required to take action.
In fact, the trigger of WF could also be controlled based on few available conditions.
For any custom determination of agents, BAdI agents' determination option is available via which one would implement the BAdI provided to determine the agents. The documentation details this nicely.
The next investigation was, what about deadline monitoring? Well, my testing so far says there is no direct option available for deadline monitoring in flexible workflows. There are some unique options available though: there could be more than one WF active with the same condition. The workflows can be ordered/sequenced. The one which comes first will be triggered and hence at a time only one WF gets triggered for one condition. Automatic release of PO workflow is available by default and documentation suggests that this option could be ordered last which would mean that when no valid workflow is found this would get triggered for PO release.
It's pretty easy to activate and deactivate workflow. Likewise copy of workflow to make another WF is pretty simple. However, once a WF is saved and activated, it cannot be edited which is definitely pretty weird to me.
So, I must agree that Flexible workflows are simple, really simple and great ease of use tool for business people. It is highly appreciable of how quickly it can be configured to get the work started. However, I have a big doubt (could be naive) that it would be highly usable for productive workflows that most customers would have in their current landscape. The readily available options for conditions, agents and likewise are really thoughtful, however, %age of time they would match with customer's requirements is something worth noticing. It definitely is a tool to be considered best in Greenfield implementation of S/4HANA.
So, how has been your experience with flexible workflow or while using other apps of S/4H?
If one would search my contributions on SCN, they'll understand why I mention favorite before PO release scenario. To be candid, as a developer while doing the customization for Release Strategy trigger and checking the approval process few years back, I had investigated the entire process so well that for any PO release scenario I'd usually start with the release strategy configuration.
So, when flexible workflow was thrown before me, my first approach was trying to find out how it's getting triggered, what is it and what is the configuration required for it. What is the use in first case when we've the wonderful Business workflows to cater to every possible scenario? The mind-set was to compare old Vs new and that only caused a lot of questions.
This reminded me of car learning experience in the US. I was trying to learn driving in the US by comparing it with the way I learnt driving in India, needless to mention the models of the car were different. My teacher said that you will not learn by comparison rather start afresh. Now someone should not consider this as a great pointer for their learning as the teacher also happens to be my spouse 😐
However, I applied the same principle with flexible workflows. One of the early learnings that I've gained is: the only documentation one could trust for SAP CP and S/4H latest is the SAP documentation. For the apps on S/4H, the documentation could be found on Fiori apps library.
This is really good and I find the quality of documentation to be good as well. The next step was to go to the app. I find using the search button to navigate to the required button is good enough.
The first intention was to create a workflow to test that it gets triggered. That was quite an effort. Workflow creation seems to be really very easy and fast and satisfies the points highlighted in documentation that business people could create without having to depend on IT team.
The first hurdle was Purchase order creation ending in failure. In such scenarios, the problem could be with gateway, UI or backend. Interestingly, I could find both a dump in the system and gateway errors. The gateway error log does not really provide accurate enough information to reach to the root cause of the issue. It provides a generic troubleshooting guide which could consume a lot of time without fixing the issue. Finally, I was shared the information that the problem was with the RFC destination and once it was fixed the purchase order was getting created. Thankfully, I had already checked the needed SPRO configuration to be done to trigger the flexible workflow. The WF got triggered and then I could jump to the questions related to Workflow. The first being multi-level approval.
The multi-level approval is very well supported and it could be controlled based on few conditions which are readily available. One of the most common scenarios being approvers being decided on the PO amount.
For every step there is a precondition:
What this would mean is, once all required approvals are done the PO is released and the same gets shown in the status tab of PO display. This is unlike my prior experience with release wherein release indicator would let us know if the PO is released. Additionally, a new tab is added in PO display screen for Flexible workflows. However, the data populated in the tab in different scenarios was not consistent enough to draw conclusion on its content.
Another interesting feature is multiple recipients could be added in the agent list and either all of them or one of them are required to take action.
In fact, the trigger of WF could also be controlled based on few available conditions.
For any custom determination of agents, BAdI agents' determination option is available via which one would implement the BAdI provided to determine the agents. The documentation details this nicely.
The next investigation was, what about deadline monitoring? Well, my testing so far says there is no direct option available for deadline monitoring in flexible workflows. There are some unique options available though: there could be more than one WF active with the same condition. The workflows can be ordered/sequenced. The one which comes first will be triggered and hence at a time only one WF gets triggered for one condition. Automatic release of PO workflow is available by default and documentation suggests that this option could be ordered last which would mean that when no valid workflow is found this would get triggered for PO release.
It's pretty easy to activate and deactivate workflow. Likewise copy of workflow to make another WF is pretty simple. However, once a WF is saved and activated, it cannot be edited which is definitely pretty weird to me.
So, I must agree that Flexible workflows are simple, really simple and great ease of use tool for business people. It is highly appreciable of how quickly it can be configured to get the work started. However, I have a big doubt (could be naive) that it would be highly usable for productive workflows that most customers would have in their current landscape. The readily available options for conditions, agents and likewise are really thoughtful, however, %age of time they would match with customer's requirements is something worth noticing. It definitely is a tool to be considered best in Greenfield implementation of S/4HANA.
So, how has been your experience with flexible workflow or while using other apps of S/4H?
2 Comments
