Hi Roland,

The API call to start a System flow should be a POST call, could that be the problem? For more information: https://docs.thinkwisesoftware.com/docs/indicium/process_flows

Hi Mark, it is a post call. :)

Hi Roland,

Did you by any change turn this "API” checkbox on? It should be off. It is for something else, and I think is already renamed in the upcoming release.

Hi Dick. I checked but it’s off. It’s really weird because it is marked as a system flow and it is synced to IAM. I even gave it a schedule in IAM just to be sure but I still get the same server response.

I will look into other API calls to see if those work and to rule out server config issues.

--

I just successfully retrieved all records from a certain table via API. Looks like this is a system flow issue specifically.

--

I found the problem. I read that system flows need the rights belonging to the user that does the API call. I wrongly assumed they run via some admin user comparable to how SQL Server jobs run. As soon as I gave myself the rights to run the system flow it worked.

Hello Roland,

To be clear, the system flow does run via an admin user when scheduled. Permissions for the process flow are only required to trigger it manually with an API call, in which case it is really just a normal process flow.

I hope this clarifies things.

HI Vincent. Got it, thanks!

I have an additional question about system flows. Suppose I schedule one to run every minute. What happens when it starts and it takes longer than 1 minute to run? Does it then start a second instance or does a system flow never run at multiple instances simultaneously?

This is rather important. For example we plan to make an email queue which we can then fill from all sorts of future functionality. Checking for new emails every minute seems a good practice but of course you don't want the flow to run multiple times to prevent strange conflicts.

Hi Roland,

System flow instances do not overlap each other by default. With the setting "Multiple running instances” you could enable this:

In the example above, the setting is turned off and a new instance will not be started until the previous instance has finished.

Well that couldn’t be any easier.  Thanks!