Advanced Workflow Best Practices
If this topic has already been discussed, please point me to the thread.
What are the best practices for using advanced workflow user action buttons? And how are you building workflows that include the buttons such that the "Save" button doesn't becoming confusing to the end users?
Here's an example:
You make a workflow with user actions to "Approve" or "Reject". So there's two buttons now available to the user. BUT there's also a "Save" button. Do you make the save button do nothing but save the record and not advance the workflow? Do you have it move the workflow down one of the submit/reject paths? Are you doing some custom work to hide the save button?
Appreciate your guidance on this - I feel like the advanced workflow could be introducing more confusion to an already confusing UI.
- Advanced Workflow
- archer 6.1
- Community Thread
- Forum Thread
- RSA Archer
- RSA Archer Suite
- Tips and Tricks
Hi, when you push any of the WF buttons, the record is first saved (automatically) in order to let the calculations run and then the workflow takes the path that corresponds to the pushed button.
In 6.1 buttons are included in the layouts and so they are subject to the DDE mechanism. This means that based on the field values, you can also enable and disable the buttons to better guide the user throughout the process (I always do this) and avoid possible mistakes.
FYI, Archer 6.2 will introduce very cool changes in the management of the WF buttons and the layouts. These changes will simplify a lot the overall user interface.
OK, so while in the workflow, I don't want the user to press save. I want them to be required to press the workflow button. Is there a way to hide the standard 'save' button or even that whole menubar (Save/edit/delete)
Again, it is not mandatory to push the Save button before a WF button, because before switching to the next node, the platform first saves the record. Of course beware if you have DDEs that changes the record content (for example a values list): this might trigger the need to save the record again.
And about hiding the Save button, no, as I know there is no way to do that. You might disable the delete button indirectly, assigning the user a role that does not include the content record delete permissions.
In theory you could disable or remove those buttons using the CSS, but this change would be system wide, not for specific users. This is easier in 6.2 where the web interfaces (end user side) are fully HTML 5 and responsive. I am now using the 6.2 and yes the pages now use HTML and CSS, so I tried to disable to toolbar while retaining the workflow buttons and it works. Again, this is a system wide change, so it is actually useless because some users would need the toolbar anyway.
Luciano - thanks for your responses. My problem is the end user experience is confusing to users of Archer when there is a workflow button AND a Save button.
Another compliant I see is that when the user clicks a workflow button, the record stays open and displays the "workflow is in progress" message box. Because workflow runs so slow, that message box is there for 5 - 30 seconds depending on the workflow actions being run. Users don't have that kind of patience. What are other people doing about this?
The Product Management (and myself of course) are aware of that and changes are in the workings (both about the save button behaviour and the performance), but not for the 6.2 release.
Getting back to the previous discussion, of course if the workflow is configured to stat on new records (no manually), the WF buttons will show up only after the first save of the record which must be done anyway.
You can use Custom Objects to hide the out of the box buttons if you wish.
Around performance, this is a high priority for the Engineering team here. The hope is to make significant strides on this for the Robin Hood release in 1H 2017, and incremental steps on it in ever release up to then.
It's not the ideal solution, which is why we are looking in to code changes to improve performance, but the processing can sped up by throwing hardware at the platform. More robust servers lead to quicker processing.