Over the weekend I was asked to brainstorm with a coworker about architecting a few workspaces to manage a process in Fusion Lifecycle. Figured that was more fun than cleaning my garage! When thinking about pro/cons with regards to setting this up, I figured it would be a good blog topic to cover a few different ways you can set up workflow approvals. Which approach you take can depend on many factors – how comfortable are you (the admin) with scripting, how large a group will be using the solution, and what level of control is needed. You may find you use a variety of these options in one tenant even.
Formal Approval Board
This is what’s set up in most default Fusion Lifecycle configurations in the Change Orders workspace.
The predefined approvers are managed in an Approvals List reference workspace (based on what team is chosen in an approval routing) but you also have the flexibility to add add hoc users.
This solution comes preconfigured in the Change Orders workspace and you can mimic that set up easily in other workspaces.
Restricting by Workflow Permission
I dug up one of my vintage (circa 2012) tenants to show an example of this approach. Here I’d created a separate workflow role to house the workflow permissions. There’s some amount of overhead in terms of access controls, but this technique is a no code option. Rather than relying on item details to specify via a user pick list who can perform transitions, you specify it via permission settings.
One drawback to this approach is there’s no option for multiple approvers, but depending on the process it may work well. I’d only have that Approval permission assigned to those I’d want to perform specific transitions and keep the General Permissions open to a wider audience. Since I had to go back to a really old tenant I realize I don’t often do this, but wanted to mention as I’d suggested this approach to my coworker this weekend as multiple approvers wasn’t necessary, but he still didn’t want everyone with workflow access to be able to transition certain steps.
Precondition Filters
Here’s another ‘no scripting’ technique! Did you know there are two precondition filters you can make use of? Precondition Filters limit the group of people who can perform the workflow transition, based on the picklists configured in the workspace. There are also options to easily only allow the record owner (or additional owners) to perform the transition.
Change Approval Templates
We’ve recently added a new app to the App Store for change management that offers slightly different flavor than what we described in the Formal Approval Board section above. Please note that this app replaces the former Change Management processes that were delivered with standard tenants in the past. If your tenant does not contain any productive data and you would like to use this app, please uninstall the previous Change Management processes before. However, if Change Management is already live in your tenant, you are advised not to install this app on top as it would not work properly anyhow. Please get in touch with your implementation partner to learn how you can benefit from this app’s new features by selectively copying them to your tenant. Standard approval flows for both Change Requests and Change Orders can be defined by using Change Approval Templates. These templates will determine the responsible coordinators as well as required approvals.
Open Approvals
Want anyone to be able to do anything? Just create one workflow permission and give it to everyone. You’ll still have that audit level of ‘who did what when where’ via the workflow history and Change Log, but you won’t have to worry about scripting or access controls. Not sure I’d employ this technique too broadly, but if you have a workspace with workflow you’ve using to a data repository, might make sense!
Hope this gives you some food for thought on different approaches to set up your workflows.
(0)