Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
SecurID® Governance & Lifecycle Recipes
SecurID Governance & Lifecycle recipes is a collection of items, to help you get the most out of your product deployment. For example, a useful report with the SQL to implement or a way to achieve some advanced rule processing.
Services 101 blogs, help to explain various areas of RSA Identity Governance and Lifecycle, to ensure you are getting the most out of the product and following recommended practices. We hope to show you lots of great features, tips and tricks that you may not have been aware of!
Please reply below with any questions or hit like if this is helpful!
We are starting by looking at workflow nodes and in this blog, specifically the "milestone" node.
The RSA Services team love to use Milestone Nodes whenever possible and find they are a great addition to any workflow. However they are surprised to find they are not being used enough by our customers to help make things easier and clearer!
Impact: High positive impact for end users, Low risk to workflow process as nothing is being changed to effect the flow.
Summary: Using "Milestone" nodes, provide a great way to help track the route a workflow has taken and give some business friendly information about what's happening, without having to drill into the processing itself. This helps business end users and admin's alike, as the Milestones are captured on the Request Tab to provide an easy to use reference point.
RSA Field Example: To put it in generic terms, what we really use them for, is to help determine why the CR has ended up where it has, without having to look at the processing workflow. We typically use them after decision nodes or to provide success/failure response.
As shown in this status image below, to meet a customer requirement we needed to identify requests created as a result of an account being Revoked within an account review and handle them differently. This is the first decision within the workflow and we use the Milestone to confirm this, without this Milestone you'd need to view the processing workflow to confirm the route the request has taken.
Then, because it’s a revoke from a review, there's a requirement to create a new CR from the workflow. This milestone not only confirms the new CR has been created but also provides the new CR id. This provides an audit-able trail and helps users with locating the new CR.
In its simplest form, the Supervisor Approval workflow could be updated to include Milestone to advise if a supervisor couldn’t be found! Without the milestone, you'd need to dig a little deeper to extract this useful information.
Usage: All workflows should include milestones where possible, especially ones which are seen by business users, to make their understanding clearer and the process more simple.
Positive business impact to provide added information and details
Reduced help desk calls, where business users don't understand whats happened and why
Aid with troubleshooting
Can be used to provide error handling
Can be used to assist with tracking/auditing
Can provide dynamic variables from the request
As an example, you could have a workflow create an additional CR, a milestone can be used to confirm the new CR has been created successfully and also provide the CR ID, as shown below:
We are using v7.1x in the example below, however most versions of the older product also have milestones available.
Milestone nodes are found under the "Modeler Toolbox", about halfway down, as shown in the image below. Just drag and drop them into your workflow.
Milestone nodes have a couple of basic properties:
Keep the node name generic and configure the milestone message under the Status options, for the following reasons
Variables cannot be used within the Node Name but they can be when using the Status options
The status options can be used to control when the milestone is displayed
A simple description of what the milestone is doing, for future reference.
Planned (Definite) - we recommend not to use this one and to stick with the Possible/Completed
To help try and explain these, we have created the following workflow that contains a Milestone for each option.
The Planned (Possible) message will be displayed even though at this point the workflow has not yet transitioned through the node. This is a way to provide some information about a potential next step in the process, which is upcoming.
Completed will populate the message only afterthe workflow has successfully transitioned through/past the node:
RSA PS Recommendation
Leave both ‘Planned’ options empty and only populate the Completed option to show the business which items have actually happen in the process flow, so as to not cause any confusion.
Milestone nodes, also make use of the helpful information "i" button, found at the end of the status details. The "i" button displays details directly from the request. The below image is the first decision in the License Review workflow which checks if the requested entitlement is licensed or not. By clicking on the "i" button it confirms which entitlement it’s referring to, this is really relevant if you have CR containing multiple items (which is a common use case)