Also, for awareness:
Not only did I reinstall the Xtension - I used a new app token and then created a new data source to use on a new test start event form - still rendering the same behavior as the one I had in production that has been running over a year now.
After testing a few scenarios - I original had 9999 listed as my limit to return.
I removed it and it’s working fine but only returning roughly 20 workflows.
We were using this connector for our NAC Audit Process. Our team was able to pick a workflow from this drop down for any workflow that was published and have a task go out to the workflow owner(s) to fix/resolve any non-compliant items we found.
Please let us know what may be causing the issue for the “list published workflows” operation.
Hey @brandiwoodson , checking with the Author now, but this sounds like something on the back end. I'll reach out to engineering to see what’s up. I’m not aware of any changes that would affect this.
Hi @brandiwoodson if you set the number to 999 does that change the behavior? This might be a limit with the number of records returned in the data lookup control. I believe it’s either 1000 or 2000 for the hard limit. If you leave limit blank it will default to 10 results as a default API behavior.
I tested in my environment with the 999 as the limit and it returned the ~100 published workflows I have and the workflow submitted as expected.
Well we have well over 1k workflows. Not sure how many are published. This should resolve the issue as an interim.
For long term resolution can you add conditions to these operators? Like published by (email), the type (prod vs dev), created by date, and the last modified date so we can continue to use it once we have exceeded this threshold?
We only care about production workflows that are published. Dates and the workfkow owners would help if possible.
Currently there is no condition option.
We'd prefer to pick from a drop down vs key enter the workflow name as text.
I will test when I'm back at my desk and confirm the adjusting to 999 worked.
Looking at the API documentation today, there is only the option to sortBy ‘lastModified’, or ‘created‘ dates with the ascending (asc) or descending (desc) parameters. I’ll check with the API team if they can put expanding the filtering options for this one on the backlog. Let me know if you need anything else on this one for the time being.
Well we have well over 1k workflows. Not sure how many are published. This should resolve the issue as an interim.
For long term resolution can you add conditions to these operators? Like published by (email), the type (prod vs dev), created by date, and the last modified date so we can continue to use it once we have exceeded this threshold?
We only care about production workflows that are published. Dates and the workfkow owners would help if possible.
Currently there is no condition option.
We'd prefer to pick from a drop down vs key enter the workflow name as text.
I finally had time to test this today!
Adding the 999 to the limit did resolve the issue. I would like to see this number increase and sorting and filter capabilities available. Considering how we use these connectors from an audit standpoint, ideally we would need the following:
Filtering:
- A way to filter by the email address against the collection of workflow owners in the workflow owner field per workflow.
- A way to filter by published in dev vs production
Sorting:
- a way to sort by workflow name
Well, it worked for a few seconds. Now it’s not working again! Sighs. I’m out of options, all of our processes that were working for audit and designer support are now broken. I will have to log a ticket but no clue how it’s going to be resolved since it’s an Xtension. :(
It seems to be staying ok with 500 at a limit. For now...
Not sure if it’s related/relevant at all, but last I knew there was a 4MB limit on the results from an NAC API endpoint. Any chance you’re hitting that limit when using 999?
