I’ll start logging the issues that I have with the workflows, as it seems I’m just wasting incredible amounts of time trying to implement some basic programming tasks.
Workflows break apart, you have to reconnect all the steps. You should version a number of workflows automatically. Workflow Steps Break Apart
Workflow validation is broken. It prominently displays “No validation errors detected” on the lower-left page while in reality the call to validate fails.
The workflow test input should remember the last test data (and give the option to overwrite with a generic one). I have to copy/paste every time I test the workflow.
Fix the documentation. In my duplicated workflow the secrets were removed.
Duplicating a workflow with a secret automatically uses the same secret for the new workflow. If that secret gets deleted, all workflows using that secret will stop working.
Add option to disable auto arrangement of nodes. When reordering nodes the nodes that are not in the tree anymore are somewhat randomly sorted so the logical order is lost.
Workflow doesn’t complete. Simple workflow needs 5 minutes to complete.
Not really a practical case, but forced to create it to debug the previously mentioned generic error.
This is amazing, thank you for compiling all the issues that I also routinely experience with Workflows. I really hope SailPoint prioritizes these fixes as workflows have great potential but are currently more painful than they need to be to work with.
You can’t visualize a workflow that is enabled. What? Just disable the save functionality. I don’t want to duplicate it, or disable it to be able to view it. Or are we supposed to download the JSON file and read that?
Am I missing the HTTP Request retry mechanism? How should failures be handled (e.g. send an e-mail)?
The UI creates invalid elements. I don’t think this error can be fixed from the UI, as everything looks fine:
In the JSON we have "value.$": null, where null doesn’t begin with $: Error: bad json path: must start with $, or as SailPoint puts it: An error occurred. Please contact your administrator.
We appreciate feedback from the community and do our best to act on that feedback, but there are two things you can do to help us organize and focus our efforts. You have provided a number of items in your assessment which are a combination of bugs and enhancements, which is difficult to manage in a single post, especially as other community members begin to comment on these items. Rather than a single post, can you please create a Bugs or an Idea Discussions for each item where appropriate? This will give us more information about each item, it will allow us to attach ticket numbers on a per item basis, and the community conversation will be more focused.
I also encourage you to schedule 30 minutes with our Workflows product manager, @tburt , to discuss these items in depth.
@colin_mckibben Andrei has centralized a wealth of information into one location. If SailPoint wants to prioritize making the product better and continue to compete in the IAM marketplace, they have to be more proactive on fixing these kinds of reported issues. I think it is unfair to request for Andrei to now create 14 different bug posts and item discussions; in my opinion, SailPoint should proactively schedule time and handle the bug tracking. I understand breaking the post into 14 different parts makes the individual issues easier to track, but it also takes (unpaid!) time out of technical implementers and community members time to help SailPoint resolve issues relating to their product.
Workflow executions report are not found anymore (after 3 days).
My test executions seem not to be available anymore. Maybe there is a policy to automatically delete them, but that information should be made clear in the UI. A “Not Found” error can mean anything.
The Get Accounts action is not able to return accounts after 5 minutes, the entire workflow is stopped.
SailPoint internal operations should succeed more often than not. But I see often errors which are not related to external factors. Retry mechanism should be implemented by SailPoint so that network issues don’t affect the entire workflow (for which is not really possible to implement retries).
Starting the workflow test often fails, and no step is executed.
We can see in the screenshot below where the test was “scheduled/started”, but after 3 retries it doesn’t find the workflow execution and an error message is displayed.
I assume this creates another issue which would explain some behavior I’ve seen.
The workflow is actually executed, but no output is shown, so there may be changes made by the workflow, and the developer has no idea that they were actually executed.
The displayed state when testing a workflow is not always correct: the workflow ended, the graph shows that the test is still on progress at the wrong node. That node was already executed successfully.
The “display name” shown in the result CSV execution repot has nothing to do with the name that I chose in the graph. You already have the technical name (stepName), use the correct “Display Name”.
The result CSV execution report should be easier to read/parse by humans.
Currently this is a mix of CSV and JSON, some information from the json “attributes” column should be duplicated in it’s own column. I am proposing at least: Display Name (the correct one), stepName.
Hey Andrei, the consistent notifications are bringing the topic to the top of our latest topics. This way it’s not always the latest topic—rest assured the topic is still here, and we’re here with you!
