PlanRadar Connect allows you to automate business workflows across cloud and on-premises apps with your PlanRadar account.
With our partner Workato, we combine an enterprise-grade workflow automation platform with the ease-of-use expected from consumer apps, enabling both business and IT users to quickly build workflow automations.
Recipes are automated workflows you build or customise that can span multiple apps with your PlanRadar account.
Each recipe comprises of a trigger and one or more actions that are carried out when a trigger event is picked up.
When recipes are started, they will run automatically in the background to look for trigger events and carry out recipe actions. When they are stopped, they will cease to look for trigger events. However, when a recipe is started again, it will pick up all the trigger events that occurred since the recipe was stopped. In other words, stop functions like pause.
All recipes have a unique ID that identifies them and can be found in the recipe’s URL. As can be seen below, the recipe has the recipe ID 47969.
The recipe above has a trigger and an action. The trigger is New or updated Ticket in your PlanRadar account – this trigger will fire whenever a new ticket is created or updated. The action Create issue in JIRA will create an issue in JIRA each time the trigger event occurs.
Triggers determine what event to listen to execute the actions described in a recipe.
Trigger events can be set off in apps (Salesforce or JIRA) when a certain event happens (new contact is created or existing ticket is updated), when a new line is added in a file, or according to a schedule (fires at a certain time or interval).
Depending on the available API, PlanRadar Connect can receive trigger events in real-time, or check for the occurrence of an event periodically by polling the app.
Find more information here.
Recipe steps are executed every time the trigger event occurs. Recipes are required to have at least one step. The most basic step for a recipe is an action, such as an action to create an issue in JIRA
PlanRadar Connect steps can be actions, conditional actions, list actions, actions that call other recipes, try/catch, etc.
For more information about steps, click here.
Every step, including triggers, brings data into the recipe. For example a new ticket in a PlanRadar Connect trigger would bring in ticket data. This data is made available in the recipe via the datatree.
The individual data fields are called datapills. You can use the datapills in subsequent steps. You can read more about datapills here.
The following is the output datatree for the trigger PlanRadar ticket. This datatree contains all the variables known to us and available for use whenever a trigger event occurs.
For example, as seen in the screenshot, whenever a new PlanRadar ticket is created, we’re able to get the following values:
Event Name
Ticket UUID
Project ID
Deedup Hash
Triggers and actions have input fields. Input fields are how triggers and actions are designed to carry out customized workflows, and they can take in variables (datapills) or constants.
When we insert variables (datapills) or constants into input fields, that’s called fields mapping. You can read more about fields mapping here.
The following is an expanded view of the Create issue in JIRA action. In this view, we can see two input fields: Summary and Description.
The variable Subject has been mapped to the Summary input field. This means that for every new issue in JIRA that is created, the Summary of this Jira issue will be the Subject of the PlanRadar ticket that will be created. For example, a new PlanRadar ticket with the Subject “Window defect“ will in turn create a Jira issue with the Summary “Window defect“.
On the other hand, the input field Description has a constant mapped to it – the words “This JIRA issue was created from a PlanRadar ticket” This means that all newly created Jira issues created via PlanRadar Connect will always have the words “This JIRA issue was created from a PlanRadar ticket” in its Description field.
For a recipe to communicate with apps via actions and triggers, it has to be authorized to interact with apps. This authorization is referred to as a connection. Connections are not tied to a recipe – a single connection can be used by multiple recipes. You can read more about app connections here.
Each time there is a trigger event, the actions in the recipe are executed. The entire flow of each trigger event through the recipe is called a job. Jobs can be successful (when actions are executed successfully), or have errors (when an action results in an error). When an error is encountered, subsequent actions are not executed. You can read more about jobs here.
The job report gives a high-level summary of the all the trigger events processed by the recipe. The entire flow of each trigger event through the recipe is called a job.
Information such as date, time processed and job IDs, can be found here. From this jobs history page, users can view more detailed information about a job by clicking on it.
You can read more about job reports here.
The job details page provides step-by-step input/output details of a single trigger event as it is processed by the recipe. This page is useful for troubleshooting recipes as users are able to view the data passed into each step and the resultant output returned after each step was executed. You can read more about job details here.
