Quality Assurance allows you to check your activities and lifecycles, in order to spot and prevent any errors, before activating and running with them.
All activities can and are strongly advised to be sent for Quality Assurance in order to be approved before being enabled. Quality Assuring your activities and Lifecycles, before putting them live, gives you and your team the chance to spot and prevent any errors in your campaigns and send-outs. This is a crucial step to avoid bad player experiences and costly mistakes for your business.
Below we will run through the flow of Quality Assuring an activity. Working within a being the main focus. We will also cover;
Hover over the activity that you wish to send for Quality Assurance and click on the icon. If you're working from a , this will send it directly to the QA stage. If it's an activity outside of a project you will instead find it in the QA portal (please note all activities sent for QA can be found in the QA portal).
To quickly navigate to the Quality Assurance of an activity you can click on the icon which will appear after it has been sent for QA.
Click on the activity that you wish to Quality Assure for the QA window to open up. Step by step you need to thoroughly check the setup of the different components of the activity. Once you've checked a component and it's confirmed to be set up correctly, you can tick the box for that section and move on to the next one.
Pro Tips: We advise that the person who set up the activity is not the same one to QA it. Instead, ask another team member to quality assure your activity, as it's harder to spot your own mistakes.
If you're running a one-man show, however, the advice is to let some time pass between setting up the activity and quality assuring it. This way you allow yourself to look at the activity with fresh eyes.
Make sure to give yourself plenty of time to QA your activities. Mistakes more easily happen when working under time pressure.
If there are no errors spotted in the activity you can sign it off. By doing this you are confirming that there are no errors in the activity and that it is ready to be activated at any point going forward. Activate or not? When you sign off an activity you have the option to activate it or keep it disabled:
Activating your activity
By clicking 'Yes' you will activate the activity, meaning that it will immediately be enabled and start running once the main trigger fires. These activities will be found in the PROD stage which is the third and final step of your project.
Please note! Scenario: An Activity has the main trigger, as a Time Trigger, at 15:00 CET. The activity includes a scheduled SMS to be triggered 3 hours later (18:00 CET). The activity is activated and triggers at 15:00 CET according to plan. The activity was then disabled at 15:30, will the scheduled SMS still be sent?
Answer: Yes, the scheduled SMS will still be triggered and sent. The same goes for any scheduled actions, regardless of what action type and what trigger is used for the scheduling.
Explanation: When the main trigger of an activity fires all actions (that are not scheduled) will be added to a queue and will be processed to trigger/send immediately. With any scheduled actions they will also be added into a queue. However, they will not fire immediately, instead, they will stay in the queue until the scheduled action is triggered. In the above example, this means that the scheduled action would stay pending in the queue until 18:00 CET when the SMS would trigger. As another example, the same logic applies for an SMS scheduled to trigger on login within the next 24 hours. The SMS would be added into the queue and wait to trigger on any upcoming logins within the next 24 hours. To sum it up: A scheduled action is not dependent on the activity being active in order to be triggered/sent. As long as the main trigger of the activity has been fired, any scheduled actions will also have the possibility to trigger within the allowed time frame (which is based on the specific action scheduling).
This is why it's essential to thoroughly QA everything before an activity is approved and activated, as once it's been triggered there's no undoing it.
Keeping your activity disabled
If you would like to keep an activity disabled you simply click 'No' after signing it off.
Any disabled and QA'd activities will remain in the QA stage until being activated. Once activated it will move on to the PROD stage.
If an activity contains errors it should be rejected. When rejecting an activity it gets pushed back to the DEV stage where the errors can be corrected before being sent back to the QA stage again.
Simply correct any raised errors by entering the specific activity and edit like usual. Once the errors have been fixed the activity can be sent to the QA stage.
We advise that the person who raised the errors is not the same one to correct them. Instead, ask another team member to correct the errors to avoid having to QA your own amendments. We recommend that only one designated person should work on correcting errors in an activity. This is to prevent any collisions when saving which easily can happen if multiple people are editing the same activity simultaneously.
If you disable an activity in PROD it will automatically go back into DEV. In order to get it back into PROD, you need to send it for QA and have it signed off once again.
Enter the QA portal to get an overview of all the activities and lifecycles sent for quality assurance. Here you will also find any activities that don't belong to a project.
You can differentiate any lifecycles and activities apart by looking at the colour to the left-hand side. Lifecycles are colour coded with a dark purple.
When you click on a lifecycle or activity, that belongs to a project, you automatically get redirected to the project that they belong to.
Please note, that this section only applies to activities in the QA portal. Should an already Quality Assured activity need to be QA'd again, or for any other reason be invalidated, you can easily push the activity back into the QA-portal. Scroll down to the section Activities that have been Quality Assured, click on the activity that you'd like to invalidate followed by clicking on the thumbs down in the top right corner.
Doing this the activity will go straight back into the Activities to be Quality Assured section again.
⚠️ Note: An activity won't be disabled by invalidating it, this has to be done manually.
Once you've finished building your lifecycle version, it's time to send it for QA.
As Lifecycle projects incorporate many components, it's never been more important to throughly check; the entry conditions, the structure of the lifecycle and the set-up of each and every player engagement.
Open the lifecycle version from In-Dev that you want to send for Quality Assurance and navigate to Define Activities view. Click Send to QA in the top right. The lifecycle version will automatically be sent to the QA status, ready to be reviewed.
From the QA status of the lifecycle, select the lifecycle version that you wish to Quality Assure for the QA window to open.
Just like when quality assuring an activity, you need to check each component of the activity slot and sign-off. Once the activity slot has been signed-off, the blue box will turn green to let you know that it has already been approved.
Tip: It is important to QA, not only the activity slot's, but also; the structure of the lifecycle, the entry conditions, the ending event(s) and the trigger and segment of each event.
Note: You will not be able to Approve the lifecycle version until all of the activity slots have been signed-off and have turned green.
Once all the activity slots for each event have been signed-off, the event track will also change to green.
Once you're satisfied with all the components of the lifecycle version, you can approve it. This means that no further changes need to be made and the lifecycle version is ready to go live.
By selecting Approve Now, the version will move to Ready status to wait to be launched into production.
Note: Players will not be able to enter the lifecycle version when enabled and in Ready. Once approved, the version will wait to be launched before it is live.
For more information about how to prepare the lifecycle version for launch, check .
If you notice anything that needs fixing or changing inside the lifecycle event, it should be rejected.
Rejecting a lifecycle version will send it back to In Dev status.
Good to Know: Any components of the lifecycle version that have been signed-off as part of the QA process before being rejected, and that were not changed whilst In Dev, will retain their signed-off status when the lifecycle is sent back to QA.
That means you won't have to repeat the QA process on parts of the lifecycle that were already signed-off 👍