What's hiding in the array/test run

Help & Questions
1

Hi!

I’m about to create a scheduled task to look for all customers, (account), without classification xyz and create contracts for these customers but I would like to see what’s in the array before I let the task loose to create contracts/havoc in Autotask.

I’m missing the possibility to take a “dry run” before scheduling the task to be sure everything is in order.

Any future plans for a “test” function or any ideas on how I can see what’s in my array?

Best Regards //Fredrik

2

Hi @Cynaps_Fredrik ,

Thanks for the great question.

We’ve considered a dry run feature, but it’s technically complex due to how outputs from earlier steps (like ticket creation) are used by later steps (like adding a note to that ticket). This dependency makes it hard to simulate workflows safely without actually running them.

Instead, here are a few options you can use to safely preview results:

  1. Mock the action: Build your workflow normally, but use a placeholder step (e.g. send an email or render text) instead of the final action. Run it and verify the output looks correct. Once you’re confident, swap in the actual action (e.g. create contact).
  2. Test the query step alone: Run just the query step, then check the logs to review exactly which records would be processed.
  3. Limit the scope: Temporarily filter the query to return just one or two accounts. Run the full workflow and confirm it behaves as expected before scaling it up.

I hope something in here is helpful for you. Let us know if we can be of further assistance.

Thanks!

1 Like
3

Thank you @travis!

Best Regards //Fredrik

4

An additional idea is to insert a step/rule which has the action of stop all processing. This is helpful not just when doing the initial design work but later on if you want to make changes to something in production.

Depending on how you’ve built your rules will determine whether you can have a rule with a single step in it to stop all (preferred) or have to add a step into an existing rule.

I prefer the single rule with the single step, because then I can simply activate/deactivate that one rule very quickly, whereas if its a step inside an existing rule, it has to be added/removed/added/removed etc. That’s especially important when working on stuff that might be in production already. Let’s me enable the rule to stop, quickly hit the triangle to reprocess an existing message, and then soon as its done processing disable the rule again. Now I can leisurely review the step output and look at the object data and variable settings.