Enhancement: SaaS Workflows Open Beta Update

[colin_mckibben]

UPDATE July 28th, 2022: As of July 1st, 2022, SaaS Workflows is now generally available (GA) and the beta program has been closed. For questions about SaaS Workflows please contact your SailPoint team. If you are a partner, please contact your partner representative.

UPDATE July 15th, 2022: SailPoint’s workflows product has been renamed from IdentityNow Workflows to SaaS Workflows. The title of this topic has been updated to reflect this change to make it easier to find in the future.

I am pleased to announce an exciting update to the Workflow service currently in Open Beta.

Over the past quarter we have invested in improving the overall Usability and User Experience in our workflows tool. Our goal is to deliver a flexible workflows experience that is both powerful and easy to use. The following post highlights some changes that are being pushed to sandbox tenants March 15th, 2022 . We believe that these changes will significantly improve the usability of the product and eliminate the need for proficiency in JSONPath knowledge.

Improving the Workflows Build Experience with a New Underlying Model

Based on user feedback, the development team has worked hard to ensure end users (1) do not have to heavily rely on knowing JSONPath to create Workflows and (2) have a clear understanding of the data that each Workflow step has access to at any given time.

In order to accomplish this, SailPoint Workflows is now built using an Additive Model instead of a Mutative Model . While this model change will break existing workflows , the data passing through a workflow is more structured and allows for a more assistive experience. The system is able to display the schema that will be present in a given step.

Additive vs. Mutative Model

Workflows was originally built using a Mutative Model. With this type of model, data being passed between steps of a workflow can be altered. This essentially results in a new dataset being passed from step to step. Although this provides greater flexibility and capabilities for Workflow users, the barrier to entry is much higher. Since the data passing through a workflow is dynamic, the system’s ability to predict the type and structure of data passing between steps is limited. This could potentially lead to more frequent errors if a proper mental model is not maintained. A mutative model limits the ability of the system to provide a tailored and assistive experience for our broad range of users.

Mutative vs Additive Model Infographic

An Additive Model provides a set structure for data being passed from step to step of a workflow. Rather than data mutating as it progresses through a workflow, an additive model adds data to an existing data pipeline. This means the overall experience can ultimately be more predictable, and usability can be improved with new builder assistance.

To illustrate the difference in experience, let’s walk through a simple workflow:

In this workflow, a new identity is created and given accesses based on department. If the employee is in the Sales department, they will get certain accesses, and if they are in the Engineering department, they will get other accesses. An email is sent once the accesses are confirmed.

Before: The Mutative Model

In the old model, users needed to know JSONPath in order to correctly tie in the correct information in the workflow:

Step checks if the department is “Sales” (Mutative Model)

This initial model required users to establish and manage a model of data passing from step to step. They also needed to be very comfortable working with JSONPath. The level of experience and proficiency required was high.

Current: The Additive Model

Our new model assists users through the workflow build process. Instead of users having to keep a mental model of data passing from step to step, our new Variable Selector experience allows users to quickly select information from the previous steps. The JSONPath is created for them; no knowledge of JSONPath necessary.

Below is the new Variable Selector experience and the output JSONPath. Please note the additional change to the JSONPath with this new model. This is where old workflows will break .

Variable Selector allows end users to quickly select the appropriate data. No mental model or JSONPath knowledge required.

Step checks if the department is “Sales” (Additive Model)

The schema of the data returned by each step along with the fields it contains are easily available for each variable input.

If you are not currently enrolled in the Workflows Open Beta, you can complete the following form to request access in your sandbox tenant.

[RArroyo (Renee Arroyo)]

Hi Colin, when will this change be activated?

[colin_mckibben]

These changes will be pushed to sandbox tenants March 15th, 2022.

[M_rtenH (Märten Hallik)]

Hey Colin,

Has this been delayed by any chance? I can see the “Choose variable” option under trigger configuration but it doesn’t seem to do anything.

It simply opens a larger text box which still expects a JSONPath expression.

Based on the screenshots/description you shared, I expected that triggers now have a list of variables you can choose between.

[colin_mckibben]

Yes, there has been a delay in launching this. It should be available today.

[colin_mckibben]

The variable selector should now be enabled. If anyone is experiencing issues, please let us know.

[esauve (Edwin Sauvé)]

The variable selector does work, although is still somewhat limited (I have to manually make changes if I want to dive deeper into a json).

The big issue I’ve encountered is that the ‘Get Identity’ action no longer works. Last time I tried this, the action worked (somewhere end of 2021), but now no longer gets any information.

[kevin_chang]

Hi Edwin! Thanks for providing the feedback.

Kevin Chang here – Senior Product Designer at SailPoint and design lead for IDN Workflows. I work very closely with @colin_mckibben on upcoming Workflows improvements.

A couple follow-up questions:

1. This may be a loaded question. How would you expect to use the variable selector? How are you manually updating the JSON path expression?
2. What was your use case for the “Get Identity” Action?

[esauve (Edwin Sauvé)]

Hi Kevin,

I’d be happy to discuss this in more detail, but for now here’s some answers via this platform.

1. If I use the JSON variable selector, it doesn’t travel down ‘enough’ into the details of a message. E.g. I wanted to check if the attribute that was changing (lifecycle state) was of value ‘inactive’. I could only select the ‘changes’ level, but not further down. I did this manually, just typing in the JSON path as I expected from the message.
2. I wanted to do a ‘Get Identity’, to get the access of the identity, which I then want to revoke via access request. This is only for non-birthright (i.e. requested) access.

Another point, I found another bug in the ‘Revoke Access Request’ action, which also doesn’t work. So in general, I think any of the actions that require an internal API call, seem not to work?

[MattUribe]

I have a similar use case to Edwin, in that I want to do a ‘Get Identity’ in order to get the “id” of an account to pass to the ‘Disable Account’ action. After a ‘Get Identity’ action, the variable selector allows me to select “attributes”, giving me the JSON Path: $.getIdentity.attributes
However, the variable selector does not offer “accounts”, which according to the data model should be there in the Identity data. Changing the JSON Path to $.getIdentity.accounts or $.getIdentity.accounts[0] doesn’t result in any account data. How is someone to provide an Account ID to the Disable Account action if there is no way to get the account ID from within the workflow?

Thanks

[kevin_chang]

Thank for you the detailed feedback @esauve !

1. IIRC the “changes” returns an array of items that Workflows currently does not support. @colin_mckibben feel free to correct me We are exploring options to display and incorporate arrays into Workflows.
2. Noted

I’m going to leave the last piece (i.e. Revoke Access Request) for @colin_mckibben to address

[colin_mckibben]

The documentation for Revoke Access Request isn’t clear on what you need to provide for input. Can you try the following configuration for this action? You can only supply one identity for revoking access, and you must provide the type, id, and comment for each item you want to revoke. Unfortunately, the format of the input data means you will have to provide static values here until we add the inline variables feature.

[esauve (Edwin Sauvé)]

Hi Colin,

We’re also connected via a different channel (yes, the same Edwin Sauvé over there) over our shared client.

I have tested the same with the values as suggested and I’m still getting that an error. Doing the exact same via the API’s in postman, I do get the expected result.

[m_kavalaskar (Manasa Kavalaskar)]

@colin_mckibben : We have a use case where we are trying to achieve to send an email notification to a manager’s email ID once a role is provisioned to an identity. This email notification needs to be sent in order to notify a the manager with next set of actions they need to take whenever an identity gets their role attached.

For this I created following workflow: “Provisioning completed” trigger followed by “Get Identity” action followed by "Send Email action" and finally “End success flow” action. However, it fails to run successfully.

Have you encountered such issue or could you please assist what am I missing here?

Thank you in advance!

[julio_macavilca]

In the screenshot you have that goes along with: Step checks if the department is “Sales” (Additive Model) I am doing something similar and it appears there you have $.trigger.attributes.department for Value 1. Your Operator is Equals. Your value 2 is Sales. Is this correct or has this changed, I’ve tried this and does not work.

[adunker (Alex Dunker)]

Are there any limits to how sleep can be used, such as maximum lengths of time, or other best practices that should be observed when using sleep? For example, could sleep be used to schedule the deletion of an account after 90 days past a trigger event?

[MattUribe]

I don’t think I would set up account deletion in the way you are proposing. What if something changes between now and the next 90 days? The deletion event is scheduled and is going to take place, even if the leaver rejoins. Performance aside, it’s probably better to use dateMath do drive lifecycle states for the account deletion use case.

[adunker (Alex Dunker)]

I would agree with that statement, really just looking for guidance on sleep usage & maximums, and that was a quick example use case.

[colin_mckibben]

Workflows is still evolving, but I would agree with Matt and use longer sleep periods with caution. We haven’t formalized limits on the sleep action, but we likely will implement some limits for performance reasons.

[Beatriz (Beatriz Lora)]

Hello @colin_mckibben ,

I’m creating a new workflow based on the “identity attribute changes” trigger and it doesnt show the section to add the filter:

Is this option still available?

I would like to call a workflow each time IDN detect the trigger “Identity Attributes changed” with a filter condition.

Thank you in advance.
Best regards,
Beatriz.