I’m using .length() in many of my workflows and I just reverified that it’s working correctly.
I think the issue here is with your update variable not persisting outside of the loop. I’m assuming your count is always returning 1? Could you confirm by putting another define variable step before your check for counter to determine that?
I’ve been seeing similar reports in the serial loops product news page:
If you could show your workflow (just the image) steps, that may help me determine the issue.
I just replicated what you were seeing and can confirm. It’s weird because it retains the string value, but when you use .length() on it, it’s like it’s referencing the original value, not the updated version that has gone through the loop.
Right after the previous using .length() against the same variable:
I encountered something similar but for integers that I was using as a counter going through a serial loop. I ended up finding a workaround using this variable $.serialLoop.succeeded - that basically returns how many End Step - Success steps occurred in the loop, so instead of you incrementing a counter everytime, you can just run End Step - Success. Then you can return End Step - Failure for everytime you don’t get a match. Once you’re out of the loop, then you can do a compare check to find out how many matches you found, sort of the same way you were going to do with the counter variable.
However second test where the counter gets updated to aa has exactly same outcome as previous case for length() and size() though counter string was aaa previously and aa now
Yes, I am seeing the same behavior you have explained. Going to try what you suggested to use “End Step” approach.
Seems like “Serial Loop” is a half cooked feature released a bit too early!! Working with Forms and Workflows still seems like we are in 90s.
Due to the issue I posted in this Use {{$.place.Holders}} as a part of JSONPath to read a variable in Workflows I had to create a workflow with individual steps instead of running them in the Loop with around 5 blocks per iteration and 18 iterations, which resulted in having around 90 blocks in the workflow. This resulted in the workflow to hang forever validating every time I clicked some item. Something that would take a minute would take 15 minutes as the page would not respond. Funnily when I downloaded the workflow it was just 40 kB, where as maximum limit is 400kB for the workflow json files. I can’t even imagine how would it handle workflows of size 400kB
Sounds good. I think both our posts are on the same page.
I’m fairly certain this is a bug, but no one from SailPoint has addressed it in the product news post or in my support ticket yet, so I’m going to assume this is a feature
I’ll update my ticket with this information to show it’s occurring with strings that are converted to integers as well, rather than just integers.
Serial Loops and Update Variables have some issues, but from what I understood, what you’re trying to achieve — wouldn’t it be better to use a Define Variable with a JSONPath? For example:
This will output an array with 2 objects, and then you define another variable with length(). Of course, if you have too many sources it will get a bit unwieldy, but you can create multiple variables with JSONPath for different source IDs and sum them up at the end!
Will only have a problem when the list returns just one item. For some reason, when using JSONPath on a list and the result is just one item, SailPoint handles it differently from standard JSONPath behavior.
Normally, JSONPath would return a list with a single item — so length() would return 1. But in SailPoint, if the filter matches only one item, instead of returning a single-element array, it returns a plain JSON object. This means you can’t use length() on it anymore, and would need to use size() instead.
So basically:
2 or more results → returns an array → use length()
1 result → returns a plain JSON object → use size()
That exactly will be an issue in my use case. Purpose of the workflow is to check for a duplicate account received from the auth source and send a notification to admins. I think for this my original idea is a simple and clean approach, ie if the components of the workflow work the way they should
I see what you mean. Just tried this in my own tenant.
What I suggested won’t work because a failure is basically a break loop as you’ve seen… I love serial loops…
Alright, another workaround! Use a regular loop instead lol!
Just tested this and it appears to work great using this to check how many items were successful since regular loops don’t break when a failure occurs!
You can see my test worked below using this variable to validate how many matches occurred: $.loop.loopOutput.successfulItems.length()
Assuming that this duplicated account would be correlated to an identity, you have the option to call the accounts API filtering by identityId and sourceId. This would return an array and you would be able to see how many accounts an identity has in this specific source! (I don’t like this idea, but I think it would avoid the huge workflow that you mentioned.)
I totally agree that your approach is simpler and cleaner.
For your original approach of the “append ‘a’ char to string to get something like ‘aaa’”… (i.e. assuming you want to stick with string manipulation to get the count).
What you can try is this:
Define the string variable with initial value of “x”.
Prepend (instead of append), some dummy char (but not ‘x’), say, ‘_’.
After the first iteration, you would get ‘_x’.
After the third iteration, you would get ‘___x’.
