Use of Parameters in a Trigger

It would be great if Parameters for a Process could be passed by the Trigger that is kicking it off rather than being limited to what is set in the Process. This would allow the same bot to be used for multiple applications by passing different Parameters to work on differing data via the trigger. It could be set by time, bot or other option. Currently it can only work on what is set in the Process which does not allow for a change in an automated process.

As an example - We have a bot that uses an SQL query to pull the data to work on. The data to use is fed from many process across the company, but all result in a similar action that can be handled by a single bot. This results in a large number of records to processes that is divided across multiple bots. By changing the query used to pull the data, we can control what is processed by source, spread the load and order the priority as needed.

If adding to the trigger is not an option, changing the Parameters should allow for saving as a new Process. This would allow the same package to be selected for multiple Process each using a unique Parameter. This would not be as clean as the having in the Trigger but would allow for multiple process using the same Package/code.

Without one of these capabilities, the only option seems to be to add the query to the code and then uploaded as a new package. This would work but requires the maintenance of multiple code lines for a single variable, which is messy and difficult to mange. Passing the variable via Orchestrator makes sense and the function is almost there.

1 Like

I dont see a big difference in setting up multiple triggers for the same process or just creating multiple processes one for each parameter value…

I agree with bcorrea, and if there are many times the parameters need to be passed, the process should be reconfigured to read the data from a queue rather than its parameters.

There is not a big difference in being able to set the Parameter per trigger or per Process. Doing it in Trigger would just eliminate a step. If it is in the Trigger, it is entered when the Trigger is created and is passed to the Process. If in Process, each Process needs to be built then each Trigger set. Not a large work load, but with it in the Trigger saves one step. Either allows the base Package Code to be reused without having to support multiple codes lines, which is the goal.

I may be misunderstanding how the Queues work but the data already exists in SQL. How would moving the data to a Queue help?

Moving it would take it outside of our persistent store, would not link to any other data sources that we use, would require some way to manage that data and then post back to the SQL source and there would still need to be some process that would be able to set the data to be used. This would seem to add layers of complication, fault points and turn the Robot into a standalone process rather than an integrated solution.
The parameter - the specific SQL query to instruct the Robot what process to run in this case - is what is needed to be passed to set what data should be processed by that bot. Can a Queue be used to pass just that one parameter? It seems it is only geared to provide the bot the data to process. Being able to pass the SQL query via a Queue could work but I could not find a way to do that. Any help would be appreciated.

The query data could be passed to the queue. If the query is stored as a string, you would just need to have the specific content of the queue item set to a string containing the query you need to run.

That worked! Thanks for pointing me in that direction. After adding the Queue the Parameter could be added in the trigger for that queue, pretty much as I was looking for.

Thanks for the help!


Hi @grefka

I moved it to the Orchestator category as it seems like your idea was already implemented :slight_smile:

If I’m wrong, feel free to move it again to the user voice and rephrase your question.

Otherwise, feel free to select the post in this topic that provided you with the solution.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.