How to test an external email automation

One you have set up an external automation, it is a good idea to test the message to ensure that it works how you have intended, prior to adding the action or alert to the route.

In addition to the testing process described in this article, we would generally recommend that new templates are set to queue initially. Once you have then seen a few coming through and you are happy with the content, you can then switch the template to send automatically (if desired).

The testing approaches described below are designed for team situations and allows the testing to be restricted to one or more users, without the fear that general day to day job progress may be trigger the message accidentally.

Testing a workflow action:

Create a team called Automation testers and add yourself to the along with any colleagues who may assist with testing.
Add a step to the stage that shall trigger the message, called Message test. This step would mimic the actual step that eventually house the message generating action.
When creating the step, set the Visibility (by user) to the Automation testers team. This will mean that only members of the team will see the button.
Add the Send an email or Send an SMS action, as appropriate, to this temporary step - choose the same template and intended target as you will on the real automation.
You can now progress a test job on a test client to this stage and press the temporary button. If you are satisfied with the output, then you can add the action to the real button that is visible to all users. You can then delete the temporary action and button. We recommend the email on the test client/contact is not an email that a user uses to log into Glide.

By following the above process, in addition to testing the template, you are also testing that the job will have the required data at the point in the workflow that is required by the template. For example, if you have a traffic light to insist a field is completed on your third stage because you merge that field into the template, and this email is generated once the job progresses beyond that stage, then the above process will also test to ensure that has been blocked correctly.

Be careful to ensure that your dummy/test client has either an email address on the client record or, if you are targeting a tag, then a linked contact, appropriately tagged, with an email address.

Testing an alert:

Where you plan to generate a message via an alert, then we would first recommend conducting a test via the above method. This will allow you to instantly see a message generated by the template.

It might also be necessary to test your planned settings for the alert. In this case, we would recommend the following approach. Please note that even if you plan to use the 'Basic client email' option for the recipient, it may be necessary to create a tag in order to limit a test to a single test client.

Create a tag called Automation testing.
Add this tag to your dummy/test client. The tag can either be added to a linked contact or via the self-tag mechanism, the choice here should mimic how you plan to deploy the automation, so as to test all aspects.
Set up your alert. For the testing phase, the only change should be to target the Automation testing tag, as opposed to the tag you shall eventually tag. All other settings should be identical.
Progress a job on the dummy client to a point where you would expect the alert to trigger. For example, if you are filtering the alert to the 'Awaiting info' stage, then get your test job to this stage.

You would logically set the dates on your test job to trigger an alert the following day. For example, if tomorrow is the 29th of April and your alert is set to trigger on the job date + 29 days, then ensure your test job has a job date of the 31st of March.

Likewise, again assuming the current date is the 28th of April, if your alert is set to trigger on the actual date for 'Sent to client' + 7 days, then ensure your actual date for sent to client is the 22nd of April.

With alerts, you may also wish to set up some tests that should not fire. For example, where you believe the current stage should filter the job out.