# ISC Workflows JSONPath validator wrong fully marks expression as invalid **URL:** \ **Category:** Bugs\ **Tags:** workflows, sailpoint-identity-security\ **Created:** [October 18, 2024, 9:03am UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068 "2024-10-18T09:03:25Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [October 18, 2024, 9:03am UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/1 "2024-10-18T09:03:25Z")
Hi all, 🙂 In workflows, this is acceptable: ![image](https://global.discourse-cdn.com/sailpoint/original/3X/0/e/0e2bf91cfcd532de3a78bcf5d69e84700cd61169.png) And this is not: ![image](https://global.discourse-cdn.com/sailpoint/original/3X/b/f/bf7c2399bcc206f635a9f0bfd3256f42a1ef89d2.png) However, according to [the documentation](https://documentation.sailpoint.com/saas/help/workflows/workflow-basics.html#:~:text=The%20Variable%20Selector%20generates%20a%20JSONPath%20expression%20using%20the%20JSON%20Slice%20implementation%20of%20JSONPath.%20You%20can%20learn%20more%20about%20the%20JSON%20Slice%20implementation%20of%20JSONPath%2C%20used%20in%20actions%20and%20operators%2C%20including%20the%20specifications%20it%20is%20based%20on%20at%20the%20JSON%20Slice%20GitHub%20repository.), We get this: > [@](#): > > The Variable Selector generates a JSONPath expression using the JSON Slice implementation of JSONPath. You can learn more about the JSON Slice implementation of JSONPath, used in actions and operators, including the specifications it is based on at the [JSON Slice GitHub repository](https://github.com/bhmj/jsonslice?tab=readme-ov-file#specs-and-references). And according to this [JSON Slice GitHub repository README](https://github.com/bhmj/jsonslice?tab=readme-ov-file#specs-and-references:~:text=%2D%2D%20negative%20index%20means%20%22from%20the%20end%22), we see that negative indices are supported: > [@](#): > > ```auto > [5] -- array index > [-5] -- negative index means "from the end" > > ``` Please fix this, such that we do not get this incorrect invalid JSONPath message. Kind regards, Angelo ---
**Author:** ![adamian](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@adamian](https://developer.sailpoint.com/discuss/u/adamian)\ **Post date:** [October 23, 2024, 2:20pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/2 "2024-10-23T14:20:58Z")
> The **Variable Selector generates** a JSONPath expression using the JSON Slice implementation of JSONPath. Hi @angelo_mekenkamp, I think the answer will be that it works as designed. (jk, there will probably be no answer) The “variable selector” itself uses a JSON Slice implementation, not necessarily the comparison action in the workflow. Regarding the actual JSONPath: > **[Creating and Managing Workflows - SailPoint Identity Services](https://documentation.sailpoint.com/saas/help/workflows/workflow-basics.html?h=jayway#building-a-workflow-in-the-visual-builder)** > > SailPoint Identity Services Documentation > When you select the trigger for your workflow, the Filter field is displayed. Enter a JSONPath expression using the [Jayway](https://github.com/json-path/JsonPath?tab=readme-ov-file#jayway-jsonpath) implementation. Note that this is not the same implementation used to select values in actions and operators. and also see [Workflows: Getting Started and Advanced - #2 by colin\_mckibben](https://developer.sailpoint.com/discuss/t/workflows-getting-started-and-advanced/8148/2#jsonpath-6) . > Workflows uses a language called JSONpath to aid the in the selection of data that can be used as input into actions and operators. JSONpath has a few implementations, with the most common one being Goessner. **SailPoint, however, uses an implementation that is closer to Jayway** , which offers a more robust set of filters and operators. This is an important distinction to remember when building and testing your JSONpath because many online JSONpath validators only support Goessner, which means you could be testing against the wrong implementation. I highly recommend you check out our trigger filter reference material in the developer portal to learn more about the operators that are available, **along with a suitable online JSONpath validator**. I am unsure why SailPoint doesn’t provide such a validator themselves, as it seems the implementation is “closer” to Jayway (but not exactly that). The same may be true for Goessner. ---
**Author:** ![adamian](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@adamian](https://developer.sailpoint.com/discuss/u/adamian)\ **Post date:** [October 23, 2024, 2:23pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/3 "2024-10-23T14:23:37Z")
The documentation also mentions that SailPoint sometimes uses Goessner, so I guess they mix and match for enhanced flexibility and increased speed. > **[Triggers - SailPoint Identity Services](https://documentation.sailpoint.com/saas/help/workflows/workflow-triggers.html?h=goessner#external-trigger)** > > SailPoint Identity Services Documentation > However, you can still select variables using JSONPath for use in future steps by adding the _trigger_ field to your JSONPath expression using the [Goessner implementation](https://goessner.net/articles/JsonPath/). ---
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [October 23, 2024, 3:06pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/4 "2024-10-23T15:06:00Z")
Thank you for the clear information @adamian! Some of which I hadn’t seen before. Based on your information it indeed looks like they use different implementations at different parts of workflows. > [@](#): > > The **Variable Selector generates** a JSONPath expression using the JSON Slice implementation of JSONPath. This bit was added on my request. I was trying before to get SailPoint to document which implementation they use for JSONPath, such that I know how I should write the code as it felt a bit too much as reverse engineering: doing trial and error to see what works and what doesn’t. The documentation team did create the internal ticket SAASDOCS-7447 and updated the documentation as a consequence, mentioning the JSON Slice GitHub repository. > [@adamian](#): > > The “variable selector” itself uses a JSON Slice implementation, not necessarily the comparison action in the workflow. I disagree with your ‘not necessarily’ part. The comparison action in the workflow does rely on input. And the documentation mentions that for this input, you use the variable selector, which is therefore using the JSON Slice according to SailPoints documentation, where they also attach the specific repository. The issue here is not with the specific implementation of JSONPath, but rather on the specific implementation of the validator, as the validator is wrongly saying that the code is wrong. Also, for other developers that are reading this. I think it is good to also be aware of [this bug in Identity Security Cloud related to JSONPath](https://developer.sailpoint.com/discuss/t/workflow-jsonpath-array-becomes-single-object/23804) where a filter will not return an array if the filter returns only one object, making it more difficult to loop over it. Suddenly you don’t loop with just one iteration, but you loop over the properties of that single object instead. ---
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [November 21, 2024, 1:03pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/5 "2024-11-21T13:03:57Z")
Got an update from SailPoint Support: > [@SailPoint Support](#): > > Hi Angelo and Team, > > Hope you are doing well. > > This issue has been logged as a bug with our UI Engineering Team. Here’s a summary of our investigation: > In workflows, the following scenario is acceptable (please find the attached screenshot): > > - Acceptable Example: > > ![](https://global.discourse-cdn.com/sailpoint/original/3X/e/c/ec2af6d053115b2bcdb2257a68f2ad98d5e3f0cc.png) > > However, the following is not acceptable: > > - Unacceptable Example: > > ![](https://global.discourse-cdn.com/sailpoint/original/3X/6/a/6aa6b23a2bb54158b5297b55824914de4cfb24e0.png) > > According to the documentation, we get this: > > > The Variable Selector generates a JSONPath expression using the JSON Slice implementation of JSONPath. You can learn more about the JSON Slice implementation of JSONPath, used in actions and operators, including the specifications it is based on, at the JSON Slice GitHub repository. > > Based on the JSON Slice GitHub repository README, negative indices are indeed supported, as shown: > > - `[5]` — array index > - `[-5]` — negative index means “from the end” > > After further investigation, we confirmed that the functionality of indexing works correctly. The issue lies with the error message displayed in the UI. > > This has now been escalated to the UI Engineering Team with the following engineering IDs: > > - SAASTRIAGE-5679 > - PLTWRKFLW-5048 I appreciate it that the engineering team have created these internal ticket IDs (after 17 days). I don’t appreciate SailPoint Support claiming that this is a summary of their investigation. This was my investigation and exactly what I shared with them from the beginning, as you can see in this forum post. Kind regards, Angelo ---
**Author:** ![tyler\_mairose](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/tyler_mairose/32/30112_2.png) [@tyler\_mairose](https://developer.sailpoint.com/discuss/u/tyler_mairose)\ **Post date:** [November 21, 2024, 2:12pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/6 "2024-11-21T14:12:40Z")
Hey @angelo_mekenkamp @adamian, While I can’t necessarily speed up the UI implementation fix, we have recently made a json path evaluator that uses the implementation we use in each area of the UI. You can switch between the two implementations with the dropdown on the right of the path. Workflows is the default. [Json path evaluator](https://developer.sailpoint.com/tools/json-path-evaluator) ---
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [November 21, 2024, 2:36pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/7 "2024-11-21T14:36:22Z")
Great stuff @tyler_mairose! With SailPoint Documentation currently pointing to implementations outside of SailPoint, we saw mismatches. Here we might be able to notice the true effect of it. However, I made some tests on your evaluator (using workflows implementation), but unfortunately also notice mismatches between your evaluator and the actual behavior of ISC workflows. Is this evaluator actually applying the exact same code as the one that is getting used by ISC workflows, or is ISC workflows using some additional steps that you are not using in your evaluator? In addition I would suggest to have the default input also have values that are arrays with 0,2 and 3 elements, instead of just 1 which you see right now. Also boolean values and integer values would be nice. Of course we can change the input ourselves, but I think it adds value to have these types in the default input as well, to speed up the testing. Kind regards, Angelo ---
**Author:** ![tyler\_mairose](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/tyler_mairose/32/30112_2.png) [@tyler\_mairose](https://developer.sailpoint.com/discuss/u/tyler_mairose)\ **Post date:** [November 21, 2024, 3:33pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/8 "2024-11-21T15:33:48Z")
The online evaluator uses a javascript library that should match the behavior exactly, we wanted to keep it javascript so that speed of the evaluation response was kept. If you detail the mis-matches we can get them in our javascript library. We do have a new cli command `sail jsonpath eval -f path-to-file.json -p "$.jsonPath"` that uses the exact workflow golang library, that you can try out. ---
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [November 21, 2024, 6:24pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/9 "2024-11-21T18:24:51Z")
> [@tyler\_mairose](#): > > If you detail the mis-matches we can get them in our javascript library. Created a separate post for this, such that this post can keep its focus on the other bug. See: > [@ISC JSON path evaluator from SailPoint does not behave the same as ISC workflows](https://developer.sailpoint.com/discuss/t/isc-json-path-evaluator-from-sailpoint-does-not-behave-the-same-as-isc-workflows/90490): > > Hi all, slight_smile SailPoint has written a [Json path evaluator](https://developer.sailpoint.com/tools/json-path-evaluator) that should be as similar as possible to the implementation used by SailPoint in each area of the UI (only workflow and event trigger implementations are supported for now). This is great and can be useful, but I noticed during testing that it is actually not matching in behavior. Using this evaluator to convince yourself that your workflow implementation will work correctly is therefore not a working strategy. Since the defau… ---
**Author:** ![angelo\_mekenkamp](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/angelo_mekenkamp/32/3386_2.png) [@angelo\_mekenkamp](https://developer.sailpoint.com/discuss/u/angelo_mekenkamp)\ **Post date:** [December 2, 2024, 1:28pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/10 "2024-12-02T13:28:59Z")
Update from SailPoint Support: > [@SailPoint Support](#): > > … > Apologies for the earlier misunderstanding. Upon further investigation, we were able to reproduce the exact same issue on our end as reported. The findings shared earlier were part of our investigation so far, and our Engineering Team is actively working on resolving this. > … > While our Engineering Team is working on the fix, please note that the resolution timeline is still under discussion. We request you to provide the above ticket references to your CSM for tracking further updates. > … > As there is currently nothing more required from Support regarding this specific bug, and since the fix is in progress, we are marking this case as resolved. Thank you for all your investigation and we would appreciate your findings here to make our product behaviour much better. > … ---
**Author:** ![lukas\_ceremeta](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@lukas\_ceremeta](https://developer.sailpoint.com/discuss/u/lukas_ceremeta)\ **Post date:** [December 4, 2024, 9:37am UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/11 "2024-12-04T09:37:18Z")
The evaluator does not work correctly either. I have a workflow for trigger ‘Access Request Decision’ where I use operator ‘noneof’ to filter out decisions other than approved. I have used this workflow for tens of working tests, however when I put the filter in the evaluator, it says operator ‘noneof’ is not supported. ![image](https://global.discourse-cdn.com/sailpoint/original/3X/7/0/7026a2938c3ef8552665b19e2a397e71c2e66518.png) ![image](https://global.discourse-cdn.com/sailpoint/original/3X/d/b/db6bb562e4fc20a2894263a5de6c3b3d6765a281.png) ![image](https://global.discourse-cdn.com/sailpoint/original/3X/7/b/7b58674d3ef2fbde11b3c98cfd01c5bc82a1e6ec.png) Also, nested jsonpath filters are broken in Workflows because they are broken in jayway implementation youre using. ---
**Author:** ![adamian](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@adamian](https://developer.sailpoint.com/discuss/u/adamian)\ **Post date:** [December 10, 2024, 1:33pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/13 "2024-12-10T13:33:19Z")
> [@lukas\_ceremeta](#): > > The evaluator does not work correctly either What is going to be the fix? Fix the evaluator so that it works 1 to 1 with the existing implementations, or document all the differences, or retire it? Having 4 different variants doesn’t sound good. ---
**Author:** ![colin\_mckibben](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/colin_mckibben/32/37182_2.png) [@colin\_mckibben](https://developer.sailpoint.com/discuss/u/colin_mckibben)\ **Post date:** [December 19, 2024, 1:54pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/14 "2024-12-19T13:54:07Z")
Hi Lukas. The workflows implementation does not support `noneof`. What you are describing is an event trigger filter, which does support `noneof`. By default, the jsonpath evaluator is set to validate workflows json path. YOu have to choose event trigger from the dropdown if you are attempting to validate an event trigger jsonpath. ---
**Author:** ![colin\_mckibben](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/colin_mckibben/32/37182_2.png) [@colin\_mckibben](https://developer.sailpoint.com/discuss/u/colin_mckibben)\ **Post date:** [December 19, 2024, 1:56pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/15 "2024-12-19T13:56:45Z")
> [@adamian](#): > > What is going to be the fix? > Fix the evaluator so that it works 1 to 1 with the existing implementations, or document all the differences, or retire it? > > Having 4 different variants doesn’t sound good. You are correct. Our initial approach to this was naive in thinking that we could take an existing open source jsonpath library and modify it to match the two implementations SailPoint uses. This has proven to be a bigger challenge than we anticipated. We are evaluating an option to provide APIs that will use the exact same libraries as our two implementations. The downside is that it will be a little slower since it will be API calls instead of javascript in the browser, but the upside is that it will be 100% accurate. Expect this to happen in late January. ---
**Author:** ![adamian](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@adamian](https://developer.sailpoint.com/discuss/u/adamian)\ **Post date:** [December 20, 2024, 7:57am UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/16 "2024-12-20T07:57:03Z")
> [@colin\_mckibben](#): > > The downside is that it will be a little slower since it will be API calls instead of javascript in the browser, but the upside is that it will be 100% accurate. Thanks @colin_mckibben, I think this is really the only way to go. I assume it can’t be that slow, and it will definitely be faster than testing the Paths in a real workflow within ISC. * * * And another suggestion, as I don’t want to open another thread: create a tool hosted by SailPoint for the tool mentioned on [Connector executed Rules | SailPoint Developer Community](https://developer.sailpoint.com/docs/extensibility/rules/connector-rules/#connector-rule-object-model) , so that users don’t have to upload their code to third party services. > - `script` - Rule’s code the connector runs. This must be an escaped string. For help with formatting, use an escaping tool like [Free Formatter.](https://www.freeformatter.com/java-dotnet-escape.html#before-output) ---
**Author:** ![lukas\_ceremeta](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@lukas\_ceremeta](https://developer.sailpoint.com/discuss/u/lukas_ceremeta)\ **Post date:** [January 2, 2025, 7:19am UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/17 "2025-01-02T07:19:41Z")
So, a Workflow Trigger Filter is an event filter and not a workflow filter… not confusing at all. ---
**Author:** ![colin\_mckibben](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/colin_mckibben/32/37182_2.png) [@colin\_mckibben](https://developer.sailpoint.com/discuss/u/colin_mckibben)\ **Post date:** [January 31, 2025, 8:59pm UTC](https://developer.sailpoint.com/discuss/t/isc-workflows-jsonpath-validator-wrong-fully-marks-expression-as-invalid/86068/18 "2025-01-31T20:59:06Z")
We have updated our JSONpath evaluator to use the same libraries as our backend services. This means the validator is now 100% the same as our event triggers and workflows.