Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog
1 2 3 Previous Next

RSA Identity Governance & Lifecycle

117 posts

In earlier releases of RSA Identity Governance and Lifecycle, a feature to limit the expiration date chosen during rule remediation was made available under the Rules->Configuration menu.  Similar functionality has been introduced in the RSA Identity Governance and Lifecycle 7.2 release for reviews so review administrators can set the maximum number of days access can be maintained with an expiration date.  The settings can be changed under the Reviews->Configuration and Rules->Configuration menus.  The same setting is exposed in both places allowing administrators to specify the default number of days for exception access and also the maximum number of days.



Once configured, reviewers will be limited in the calendar control available to select expiration dates.  The default date will be selected based on the configuration and the user interface will not allow selections beyond the maximum number of days.


For additional information on this update – please check out this additional context:

In earlier release of RSA Identity Governance and LIfecycle, the Generic REST connector was introduced and is being used by many customers.  In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced the matching connectors to allow you to collect entitlements, accounts, and identities from endpoints using REST API calls.  REST is becoming a standard way to interact with systems returning data in a well defined structure (JSON).  One of the key advantages is that if endpoints change implementations, you don't need an entirely new collector but instead simply adjust the REST API calls configured slightly.


To get started, create a new collector and select Generic REST as the data source type:



The following video dives deeper into what to consider when creating a collector and how to handle things like pagination, authentication, and how to debug the configuration.  A REST client like Postman is recommended to determine the right apis to call and how to parse the responses:

In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced a new component that can be used on dashboards to display a single value "fact".  Dashboard Facts are a convenient way to provide high level information on a dashboard with click through support to dive into the details.  Combined with other dashboard components you can build very powerful dashboards targeted to specific users or roles.


To create a dashboard fact, you will need to decide on the fact you want to show.  For example, maybe I want to know how many applications have been onboarded into RSA Identity Governance and Lifecycle.  Dashboard facts can appear on any type of dashboard (Welcome, Object, or Topic level).  Along with the fact you will want some visualizations like a name, a colour for the fact, and some descriptive text to explain why anyone cares about the fact (or to give the context for the fact).  When creating a fact, the most important thing to keep in mind is what is the fact meant to convey.  For example, if I show a number of 100 is that a good thing or a bad thing someone may want to drill into more.  For this reason, keep your facts concise.  In addition to the fact itself, you can configure an url that allows the fact to be clicked on to get more details.  This is especially useful to provide a high level dashboard that links to a lot more content like a report or a detail screen within the product.



It is highly recommended you start with thinking about the fact you want to present and is there an efficient way to get the value to display.  Performance is the key as the query will be run everytime the dashboard is displayed.  RSA recommends using values that are not calculated at runtime.  For example, use counts for objects that are gathered daily and stored in the public view PV_TELEMETRY_DATA  rather than a query that does an actual count every time the query is executed.


To showcase this new feature and help system administrators, the 7.2 release includes a new dashboard available out of the box called 'System Admin' Dashboard.  Facts like the number of admin errors are shown on this dashboard with click through support to take the end user to the actual admin errors.


For additional information on this update – please check out this additional context:

Two new review analysis have been introduced in the RSA Identity Governance and Lifecycle 7.2 release:




 Never Reviewed

This new category finds any access that has been reviewed by any reviewer in any review.  This helps reviewers to identify items that have never been reviewed in their list and take appropriate actions.  Other review items will likely have similar review actions to previous reviews unless a user's role or status has changed.


 Expiring Soon

Exceptional access given for access raised as a violation will be flagged by this category if the expiration date is within 30 days (default) from the time of the review generation.  The default value can be overridden by navigating to Admin->System->Settings.  This allows reviewers to review the access and make a decision before the access expires and goes through another round of remediation.


These new categories can be configured from the Analysis & Guidance page of the review definition along with the other existing categories:


For additional information on this update – please check out this additional context:

Sean Miller

New Feature: IMAP Support

Posted by Sean Miller Employee Feb 11, 2020

Email protocols have evolved and to remain modern and provide secure solutions theRSA Identity Governance and Lifecycle 7.2 release now includes IMAP/IMAPS as a supported protocol for receiving inbound emails.  This can be configured on the Admin->Email->Settings page.



IMAP is recommended to use for the inbound server protocol rather than POP3 and many organizations are now requiring the use of this protocol.

In the RSA Identity Governance and Lifecycle 7.2 release the user interface is cleaner, more consistent, and provides a more cohesive experience.  We have moved to a style guide based reusable component framework.


This release includes redesigned UI components and features such as:

  • Dialogs
  • Buttons
  • Tables
  • Charts
  • Links
  • Card based component layout
  • New icon set for high resolution displays


Color Palette and Fonts

A palette of named colors for styling components is used now rather than hex codes used in multiple places.  This means one css file controls all color palettes making it consistent across all the UI components in the application.  

The default font has now been set to "Open Sans" and a consistent font sized used based on the context (Title: 20px, Heading: 16px, SubHeading: 12px ....).


Buttons are now shown as primary, secondary, and tertiary buttons to help highlight the primary action, secondary action, and other actions that a user might be interested in.  Some buttons are now associated with action icons providing a visual cue to help with accessibility.



A new icon set for higher resolution has been provided.  This improves the scalability leading to faster performance and browser loading, avoids pixelation on larger displays, and avoids image redundancy.


Similarly, loading icons have been replaced by a standard spinner icon that is more scalable.


Notification Panel

The notification panel accessible from the top right of the main menu now has a cleaner user interface incorporating card based component layout with notifications grouped by date.


Progress Bar

Progress bards have been redesigned to look cleaner and render better in browsers.  Several browsers experienced clipping issues and the component was not performant.



The layout of dialogs has been changed so the header background color to a primary color (blue), new button design is used for primary and secondary actions, and links are highlighted in blue. 


Tabs and Breadcrumbs

Tabs are now shown as a minimalist component where the selected tab is denoted by an underline.  Earlier iterations were much busier, required rendering time in browsers, and proved to be distracting in user interaction testing.

The title of the page is shown now above the breadcrumb, highlighted in blue.  The breadcrumb shows a detailed path and allows the user to navigate to any page present in the path (earlier versions just allowed navigation back to the home page).



Tables have been redesigned with a modern them and includes a redesigned pagination component that is consistent across the application.  The go to page functionality has been separated out by aligning it to the bottom right of the table.

Table filtering has changed so the active filter is blue and other available filters are white.  Disabled filters are shown with a gray background.  Grouping and searching fields have also been made more consistent and clean in this release.



Links are not represented in a blue color and appear red when hovered over with an underlined font.



Charts now have a modern theme and layout with improved animations.  A standard color palette is used and new options have been added to download charts in the desired user format.


Form Elements

The active field is now more evident in forms using a blue border to highlight text box and text area controls.


What's New Page

The what's new page has been redesigned to showcase key features in the top card based slider.  Other features are also shown on this page in standard cards below the slider.  The features here are controlled by entries in the and additional text/highlights can be added in for customer environment's.


These are just some of the exciting changes we have made in the user interface this release.

The topic of 'System Data and Diagnostics' is not new news.  We announced these capabilities in 7.1.1 in this blog.  However, in the RSA Identity Governance and Lifecycle 7.2 release we have added additional data points and functionality.


It is important to understand the 'System Data and Diagnostics' feature is made up of two key parts:

  • Gathering
  • Sharing


All configuration for this feature is done on the Admin->Diagnostics->System Data and Diagnostics page.




This is a scheduled task that runs daily to calculate and store off data points.  Once stored, these data points can queried using the public view PV_TELEMETRY_DATA.  These are extremely useful to show the state of the system, show trends over time (like application onboarding), show return on investment (decreasing trend of rule violations), and highlight gaps (number of orphaned accounts).


A key value add of having the gathered data is that it is static data perfect for reports and dashboards instead of real time potentially expensive count queries.


Data is gathered from yesterday and beyond to avoid incomplete data for today since the time the gathering runs versus collections and other activities may vary


In additional to gathering the data points, it is recommended you configure the system to also share this data with RSA.  This document describes in detail what is collected and shared here.  It is important to note that there is no personal data shared like user information and with the exception of the customer name, there is no other identifying information gathered.  By providing the data to RSA, this helps RSA understand how customers are using the product and where we should be investing, what areas are not being used which helps us make deprecation decisions, and understand the size of deployments and identify opportunities where RSA can have conversations to help our customers.  Lastly, this also helps RSA identify key customers to participate in beta programs or design partnering based on their use of the product.


To share the data, the IGL server needs to be able to access the web site -


For additional information on this update – please check out this additional context:

In the RSA Identity Governance and Lifecycle 7.2 release, we have enhanced the unauthorized change detection feature processing:

  • Filter by Accounts
  • Filter by Users
  • Filter by Groups
  • Detect Unauthorized Missing Access


Filter By (Accounts, Users, Groups)

When creating a new unauthorized change detection (UCD) rule, the rule will continue to apply to all accounts in the system by default.  To have the rule take action for specific accounts or exclude specific accounts click on the “All”.

Any UCD rule existing prior to this version will default to ALL accounts as that is the equivalent functionality in prior releases.  

Clicking on the “All” will produce a pop-up which is our standard filter screen where you can limit the accounts.



Detect Unauthorized Missing Access

The Unauthorized Change Detection rule previously was only capable of detecting any new access that was collected for a user which was not authorized.  This enhancement will detect when the selected access is removed from a collection for a user which was not authorized.

As seen in the UI there are two new check boxes.  The first ‘Detect New Access’ represents the old functionality and ‘Detect Missing Access’ represents the new functionality.  Any new rule will default so that detect missing access DISABLED as that is consistent with the default action of the rule in prior versions.  You must go and enable this check box by choice.

Any UCD rule that exists in a prior version will be migrated so that the detect missing access is also disabled keeping the execution of the rule consistent with prior versions.



For additional information on this update – please check out this additional context:

Sean Miller

New Feature: User Pictures

Posted by Sean Miller Employee Feb 11, 2020

User pictures have been introduced in the RSA Identity Governance and Lifecycle 7.2 release to help various RSA Identity and Governance actors make decisions when reviewing, approving, or remediating user's access.  An image can now be associated with a user and is displayed on the user detail screen and the user information popups throughout the product.  The image is also shown for the active user in the menu bar when logged in.



User pictures can be managed a few different ways be default:

  • Self - A user can modify their image on the user's detail screen
  • Direct reports - A supervisor can set the image for any user's they can edit.  Usually this equates to their direct reports but this can be controlled through security context configurations.
  • Administrator - Pictures can be directly uploaded through the Admin->User Interface->Files (Users) page.  The filename must match the userid of a user before it will be used.
  • Web Services - Pictures can also be uploaded using the setUserImage web service.  This web service requires a token for a user that can modify the specified user.  This is a useful way to manage images in bulk leveraging curl calls.  There is also a getUserImage web service that can be used to access the picture for a specific user


The security for who can edit the images can be controlled by granting the User:Edit Image, User:Edit Self Image, and User:Edit All Image entitlements to the desired users.


For additional information on this update – please check out this additional context:

Within Account Access and Ownership Reviews, the Maintain and Revoke buttons are mandatory and cannot be hidden or removed. When a reviewer selects Revoke against the account, this will result in a change request being generated to delete the account.


It is not always possible to delete accounts and it has been asked by multiple customers how the Revoke button behavior can be changed to perform disablement of the account or even disablement and removal of access.


The attached document, created by RSA Professional Services, provides details on the out of the box components used and steps followed to create an Approval Workflow to:

  • Reject the automatically created Delete Account change request
  • Create a new change request to disable the account
  • Create a new change request to remove access (if required)

Hey all,

I hope everyone had a great break over the holiday season and is ready for an exciting 2020!

We have loads of fantastic content lined up and cant wait to share it with you all! 


Before that however, we wanted to reflect on 2019... and what a great year 2019 has been for RSA IGL with you, our RSA Link community - we launched a monthly newsletter, followed up by a live webinar, not to mention all the other great content and blogs that were published!


I wanted to share a quick summary of all this content (see details below with links) and thank all those who helped.

It takes a lot to put together the newsletters, webinars and blogs - without the whole team, it simply wouldn’t happen.


Specifically, a HUGE thanks to:


Key Stats:

  • Total newsletters published: 9
    • Newsletter views: 18,000+
  • Total webinars hosted: 5
    • Post Webinar recording views: 1000+
    • Total Webinar registrants = 750+


Don't forget:


2019 Webinar Summary - Click the link to playback the webinar

#1 - July Link

  • 1st ever webinar introduction
  • Product Demo: New review features by Mike and Andrew
  • Meet the customer: Investec
    • Discussion on their deployment, success and key processes

#2 - Aug Link

  • RSA Datareach demo with Balaji and Pradeep
  • RSA Webservices Demo with Sean Miller

#3 - Sept Link

  • RSA IGL Roadmap with Aaron Beaudoin

#4 - Oct Link

  • RSA University info and update including courses available & certification
  • Meeting the Customer: BOK Financial
    • Discussion on their deployment, success and key processes

#5 - Nov/Dec Link

  • Dashboards
  • Meet the customer: Dell Tech
    • Discussion on their deployment, successes and Service Now


 2019 - Newsletter Summary

#1 March Link

  • Recommended Practices: Joiners, Movers and Leavers
  • IAM Blueprint: Bulk application collection
  • Success Wire: Food manufacturing
  • RSA Integrated Solution: RSA IGL & AM RSA SecurID Access Prime

#2 April Link

  • Recommended Practices: Sizing guidelines
  • IAM Blueprint: Bulk attribute updates
  • Success Wire: Automotive Company
  • RSA Integrated Solution: RSA IGL & RSA Archer
  • RSA Deep dive: Datareach solution

#3 May Link

  • Recommended Practices: Upgrade/migration
  • Success Wire: Dell Tech
  • Product Feature: Deep dive on upgraded rule engine
  • RSA IGL Telemetry Reports

#4 June Link

  • Recommended Practices: Backups!
  • Success Story: Healthcare
  • Support quick tips 1/3
  • Product Feature: New review features
  • RSA Blueprint: RSA IGL and RSA Archer

#5 July Link

  • Recommended Practices: Non-personal Accounts (NPA)
  • Support quick tips 2/3
  • Product Feature: Deep dive on workflow system status
  • RSA Blueprint: License Insights

#6 Aug Link

  • Recommended Practices: Application Onboarding
  • RSA Polls – we need your help
  • Product Feature: Deep dive on webservices
  • Support quick tips 3/3
  • RSA IGL & Services Now summary

#7 Sept Link

  • Recommended Practices: Performance checks
  • Datasheet: v7.1x
  • Product Feature: v7.1.1 Reduce Access Risk

#8 Oct Link

  • RSA IGL AWS Deployment guide
  • ACME Performance Guide
  • Datareach video
  • RSA Charge 2019 summary

#9 Nov/Dec Link

  • Reports, charts and dashboards
  • Tips/Tricks: Friendly date formats
  • RSA University update and summary


Other notable items to check out

Blog: All about reports/Charts & Dashboards

A summary of what reports, charts and dashboards are with info on how to use them and some examples to get started

101: Workflow Node summary

A summary of all the RSA IGL workflow nodes at a high level, with links to more detailed blogs as we add them

101: Workflow node – milestones

More details and information on this workflow node – what its for and how to use it

Tips and Tricks: Business Friendly dates

How to use RSA IGL to add more “business friendly” date formats into your workflow's or emails

101: Reports – finding all app-roles

A handy report and guide to find all app-roles within the DB

PS Beta – Risk dashboard

A new look dashboard based around risk – showing off some of the great things you can do with RSA IGL

Advanced SOD updates

A blog from Aaron around Advanced Enterprise-wide SOD violation analysis and visibility

RSA IGL Training

A blog about all things you need to know about RSA IGL Training

New Feature: Web services

A blog and video from Sean Miller on the new webservices features

New Feature: Rule improvements

Reduce Access Risk - New Streamlined and Intuitive Violation Remediation Experience

New Feature: Log Artifact

Find out about the great changes we have made, to make supporting you easier

 New Feature: Display Views

Learn about creating display views in the latest product version

What's new in v7.1.1

Learn all about the great features added to v7.1.1

New Feature: Diagnostics

Learn all about the new diagnostic capabilities

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 "Create Admin Error" node. 

Click the images to enlarge if you need!

Product Area: Workflow's

Note: A summary of all workflows is found here: RSA IGL Services 101: Explaining Workflow Nodes - Summary

Workflow Node: Create Admin Error

Time to apply: <10 minutes

Impact: High positive impact for administrative users and support, Low risk to workflow process and performance as this node has a very low data footprint.


Summary: "Create Admin Error" nodes provide a great way to help log success or failures from within workflows. These results can be captured in a clear and meaningful format and are then available within the RSA IGL UI (Admin > Admin Errors > Summary) and via reports/charts.


Capturing Admin Errors helps to highlight processing issues that require attention to administrative users without them having to drill down in to workflows. 


RSA Field Example: To put this in to a real-life scenario, it’s a common requirement that Active Directory accounts have the password reset and are moved to a different OU when the associated user is flagged as a leaver.


This would be achieved using Provisioning Command nodes (1) within the fulfillment workflow. These Provisioning Command nodes then call the relevant AFX capability on the Business Source to perform the action and provide a status of 0 if successful or -1 if unsuccessful (2). Further details on the values and how they can be referenced as variables can be found here -


A Decision node (3) then separates the successful from the unsuccessful allowing the Create Admin Error nodes (4) to return different errors depending on the result.


The Create Admin Error is then configured to capture the relevant details in a clear format that is easily understood by administrators.


Below is a format we typically use when configuring Admin Errors for the following reasons:

  • Highlighting the status (WARNING) at the start of the message helps focus attention

  • Including the associated process (LEAVER) helps sorting/filtering/reporting and can form part of daily checks

  • Including dynamic variables from the workflow makes the message more meaningful and easier to track

  • Inclusion of the Change Request ID enables easily linking to other tables/views for extended reporting options

  • Pipe separator simplifies report query



The Admin Errors are then visible within the UI from the Admin > Admin Errors screen

And can be easily extracted in to a report format which can be emailed on a scheduled basis or added to a dashboard to form part of the daily checks.

As mentioned, the inclusion of the CR ID in the Admin Errors provides a logical join to the CR views which provide useful additional detail such as user details, dates, times, days late, etc.


Within the above report, the join was achieved using the following query:




The REGEXP_SUBSTR function uses the pipe separator (|) as a way of determining the string to return. Once joined to the PV_CHANGE_REQUEST_DETAIL view, this can be easily extended, for example:




ON pCRD.Affected_User_ID = pUSR.ID


Usage: All workflows that contain provisioning activities and provide status response (Provisioning Command node, Web Service) should include error handling, where possible.


General Notes/Benefits:

  • Reduce troubleshooting effort (no need to dig around in workflow)

  • Help create audit trail

  • Quickly and clearly highlight issues that require attention

  • Easy to configure

  • Very low data footprint so won’t impact performance

  • Ability to include variables in error messages provides huge flexibility

  • Populated to V_AVR_ADMIN_EXCEPTIONS view

  • Ease of reporting/dashboards

  • Admin Errors are not included in data purging although can be manually deleted from the UI if required





  • We are using v7.1 P04 in the example below, however most versions of the older product also have milestones available. 
  • Create Admin Error nodes are found under the "Modeler Toolbox", about halfway down, as shown in the image below. To add a new node to your workflow, just single left-click the required node icon from the left-side panel then double left-click anywhere in the middle area to add that node.

Create Admin Error nodes are made up of 3 sections:


Available to select from a drop-down list and can be used as grouping/sorting criteria on the Admin Errors page.



Drop-down select of either Low, Medium or High


Error Description

Free text box


As mentioned above, within the Error Description box you can also use variables from within the workflow. The use of dynamic variables makes the message more meaningful and also provides greater flexibility when it comes to reporting.


RSA PS Recommendation

Unless absolutely necessary, RSA recommends to only create Admin Errors for the failed/un-successful changes. This helps keep the Admin Error page lean and focus attention on only those items that require action/remediation.

Please find attached our first newsletter of 2020!


DONT FORGET - please register for the January RSA IGL Webinar - Click Me


Our goal of this newsletter, is to help share more information about what's happening and key things for you to be aware of, specifically for RSA Identity Governance and Lifecycle.

This is a monthly release, so you can expect a new Newsletter at the start of each month.

Please feel free to leave comments/suggestions (positive or negative!) below and don't forget to hit that "like" button too 


Current Edition:

  • Issue #10, January 2020: See attachment below 
    • Note:you should be able to view this in a browser, or download/preview the document too. Any issues/questions, just reply to this!

Previous Newsletter Editions:


Previous Webinar Recordings: (Note: you must login to view these)

RSA IGL 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!


This blog provides a high level index and summary of each workflow node available, taken from v7.1x of RSA IGL. As we dive into more detail of each node, we will provide a link below, to click and get more info. For example, please click "Milestone" in the table below.

If there is a specific node you would like to know more about, please let us know in the comments below

Workflow Node Summary

The workflow editor includes processing nodes common to and also specific to request, approval, fulfillment, and escalation workflows. Nodes are the building blocks you use to create and modify workflows. This following table lists nodes that you can use in request, approval, fulfillment, and escalation workflows.





Used to define a activity for a change request.


Used to define an approval for a change request.

Approvals Phase

Used to allow change request items to be approved as groups at the same level.

Cancel Change Request

Used to generate a milestone to cancel the entire change request processed by the workflow and revert all changes completed in the change request, reject the entire change request processed by the workflow, or put the change request in an error state.

Complete Assigned

Used in an escalation workflow to mark work assigned to a user (through an approval or activity) as completed.

Create Admin Error

Specifies the type of admin error to create for an administrator.


Evaluates a condition(s) based on a true or false result for outgoing transitions to an action or stop delimiter based on whether or not the condition exists.


Suspends a workflow temporarily based on date criteria. The date could be a specific date, the change request fulfillment date, a system calculated date relative to current time, the result of a java method that returns a date, or the result of a SQL query resulting in a date.

Form Approval

Used to define an approval for a change request generated from a form.

Form Fulfillment

Used to define a fulfillment for a change request generated from a form.

Fulfillment Handler

Invokes a Java class to fulfill changes in a request.

Fulfillment Phase

Used to allow change request items to be fulfilled as groups at the same level.

Get Remaining SecondsUsed to store how much time remains for a calculated due date, performs some escalation outside of the assigned user’s control, and then updates the due date for the assigned user based on the earlier recorded remaining time.

Java *

Provides an interface to a Java method passing any parameters and returning a true/false result you can incorporate into a workflow.

The Java node, can evaluate conditions and perform actions in a workflow required for an approval and to initiate completion of an activity.

Note that if you use the Java node in a workflow or use the Java tag in workflow forms, you should place custom classes or jars in one of the following directories:

  • aveksa.ear/aveksa.war/WEB-INF/plugins/JavaNode/lib
  • aveksa.ear/aveksa.war/WEB-INF/plugins/JavaNode/classes

The sample Java Node workflow is deployed and references classes in these plugin directories. The source files for the samples are also included in the plugin directory under the src directory.

Job State

Specifies a job state the pauses a workflow: Canceled, Error, or Suspension

Manual Fulfillment

Used to handle a fulfillment manually and not automatically by the system.

Mark Verified

Used to indicate that changes marked as pending verification should be marked as verified.


Provides high-level status information about a workflow milestone you want displayed in a change request.

Next Value

Returns the next value for a given job level workflow variable. If no value is returned (the last value was previously retrieved), the node returns false, which can be tested on an outgoing transition. If a valid value is returned, a true return code is provided. This node is typically used to iterate through an array of values to get the next value in the array..

Provisioning Command

Used to complete a provisioning command in a data source for a particular business source.


Used to assign an approval or activity to another user.

Reset Password

Used to generate an email notification prompting a user to retrieve a password that has been reset for the user.

REST Web Service *

Invokes a REST call to an endpoint. The responses and results from the calls are stored in the workflow variables based on the configuration in the node. This information can be used in a workflow’s decision logic.

The node supports:

  • GET and POST methods
  • Basic authentication
  • Header parameters.
  • XML and Properties response types
  • Parsing of the response using XPath and RegEx expressions.

Run Report

Generates a report configured for the node in the workflow.

Run Review

Used to generate a user access review associated with the node.

Send Email

Generates email you want from the workflow. It supports the use of workflow variables or runtime workflow information to specify the To/From portions of the email.

Set Value

Creates or updates a job level workflow variable(s) using the value(s) provided. The value can be a literal or use other workflow variables that are evaluated at the time the node is executed

SOAP Web Service *

Invokes a SOAP call to an endpoint. The responses and results from the calls are stored in the workflow variables based on the configuration in the node. This information can be used in a workflow’s decision logic.

The node supports:

  • POST method
  • Basic authentication
  • WS-Security
  • Generic MIME Header
  • SOAP based XML response type
  • Parsing of the response using XPath and RegEx expressions

SQL Execute *

Runs an Insert/Update/Delete SQL command or a stored procedure where no result set is needed. It runs against the system database (AVDB). This node supports variables from the workflow with the SQL.

If you want to use an output parameter from your stored procedure (say, ‘success’ or “failure’ status) as a workflow variable for subsequent processing, you must define the stored procedure as a function and use the following syntax:

select sp_update_db (‘JOE’, ‘SMITH’, status) status from dual.

SQL Select *

To be updated.


Used as the start delimiter for a workflow.


Used as the stop delimiter for a workflow.


Calls/interjects another workflow as a subprocess of the current workflow. This node is useful in compartmentalizing work items or to improve maintenance or re-use of workflows.

Text Node

Used to enter text into a workflow.


Used to connect two workflow nodes (processes) unidirectionally with a straight line. Transitions can be conditional or unconditional. A conditional transition occurs only if a particular condition is true. An unconditional transition can occur regardless of whether a condition is true. A transition is visually represented as an arrow.

Undo Changes

Used to generates changes to reverse the requested changes that have been fulfilled.

Wait for Verification

Used to create a database watch for evidence of a change request fulfillment.


Note: Not all controls and types are available for every workflow type. Also, nodes with an asterisk symbol ( * ) are designed for advanced application. These nodes should be implemented carefully because poorly defined nodes can negatively impact workflow performance.

RSA IGL 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!


Product Area: Reports/Charts/Table's

Data: App-Roles

Summary: Application roles collected within "directories" are not located in the PV_APPLICATION_ROLE view but are instead found under PV_DIRECTORY_ROLE view. If you use directories and collect in APP-ROLES, you must take this into account for all your reports/charts that you create, so that you dont miss out any information. 

RSA Field Example: If creating a report/chart to display all app_roles within RSA IGL which have a "privileged" flag set to "yes", you will need to take into account both these tables in the SQL.

SQL Example:

from avuser.pv_application_role
where lower(privileged) = 'yes'
union all
where lower(privileged) = 'yes'


These images show where the data is found.


Within the Directory "Navision - SQL Database" we can see the "app role" called "db_access_admin"

When searching against PV_APPLICATION_ROLE table - the result is not found

When searching against PV_DIRECTORY_ROLE table - the result is found


Thought I'd share this to save others time if they weren't already aware.