Thanks Thomas, my issue is that it’s returning not only the JSON I’ve requested but also in this example, the JSON output of the steps before Get Access, I.e. the identity attributes changed trigger’s input. I’ll try and post a better example tomorrow. The two behaviours I’ve noticed are
if I have steps before the operation step, the input into the step shows outputs of ALL previous steps in the input field.
this happens regardless of what I may have put in the input variable for the operator. I.e. I tried using $.trigger.identity.id as the first value(variableA) and a string as the second but the test run still showed outputs from previous steps as the input to the operator step.
GA being “All Tenants” or “By Request Yet”. Not seeing this in a number of SBX tenants I’m working in. Also curious if there was some kind of SailPoint communications (Compass, Developer, etc.) related to this that we can pass along to the clients we’re working with.
Is there any issue going on with Workflows? We have configured few workflows which are getting triggered based on Identity Attribute Change and they were working fine until day before yesterday.
From yesterday, none of the workflows are getting triggered. I tried to test one of the workflow in which based on Identity Attribute Change, email will be sent and for that I’m getting an error.
Hi Ed. Sorry for the confusion. Workflows won’t show up in every IDN instance - they’re available to customers who participated in the Beta, or who have our Suites (Business or Business+).
Details on the suites are here: https://www.sailpoint.com/identity-security-cloud/. (note that page is being updated to reference workflows…just running a few days behind since we only recently GA’ed).
@ambesh
Did this email action exist in this workflow prior to July 1 and did you modify this action in the existing workflow? We released an updated version of the “Send Email” action as of 07/01 that supports non-id tied recipient lists. If you are putting in manual recipients that are not tied to IDs that may be the issue. In order to not break existing workflows, the old actions will remain in the existing builder. If, however, you want to take advantage of features in the new action (like non-id related recipients) you would need to drag in the new action into the builder and configure that new action.
@RTASB I think I understand your question. You can reference just the data for the step in question by using the $.Action. For example if you are using the “Manage Access” action and you want to provide the array of items returned from “Get Access” you can either use the Variable selector and choose the specific action or the JSON would be $.getAccess.accessItems which is the array of items you returned from your “Get Access” action.
I was hoping it would be able to do something like:
i.e. a string ‘contains’ on the array response from Get Access JSON for the string I’m after but the latter gives me a false.
@tburt
I have created this workflow last week only using template available in updated version “Template: Notify Access Request Decided” where I edited trigger to Identity Attribute Change. So I believe it is the latest version workflow builder. And this was working until few days back.
Also there are few other workflows which we created to generate certification but now they’re also not running when Identity Attribute is changing.
We have been waiting for the Workflows to be pushed to the production environment. Are you all using it in sandbox, or have you been able to get it into production?
This topic is in regards to the beta release of Saas Workflows. Since the workflows beta is now over, this topic has been closed. If you wish to discuss workflows with the community, please create a topic in the IdentityNow channel.
This issue should be fixed now. The issue was with adding support for multiple addresses where the input expected more than one. It now expects one or many.
