Automations are a fantastic way that you can automatically respond to changes in data, taking action without delay.

Planhat provides a library of configurable Automation Templates, covering a variety of use cases, but you can also build completely Custom Automations.

In this article, we take you through some examples of Custom Automations, explaining the different components in detail. These examples will help you better understand how Custom Automations work, and give you some inspiration for when you build your own.

In the hierarchy of Planhat data models, the Company model is at the top, with other models (e.g. End Users, Licenses, Opportunities and Workflows etc.) linking to the Company. You might initially think you can move data from a Company to an associated Workflow (for example) using a cross-model Formula Field. However, while you could use a Formula Field to roll data from a model "up" to the Company, this isn't possible in the other direction.

Automations come to your rescue in this case, as you can use them to transfer data between any models. So what could this sort of Automation look like?

In this example, let's say we have an custom field (of type End User or Text - we discuss the implications of this later on in this example) on the Company model for the "Scheduling Contact", and when a Workflow is created, we want to save this to a custom field on that specific Workflow.

The trigger in this case is "Workflow created". We'll select "created with anything", as we want this to apply to all Workflow records. We don't need to define trigger filtration in this case.

In order to get the "Scheduling Contact" from the Company record associated with the Workflow record, we need to identify and retrieve that Company record, so we have access to all its fields. We do this using a "Get" step.

Where does <<object.companyId>> come from? This is an example of a replacement code. These are dynamic references. What do we mean by that? Let's break it down.

Bringing this together, <<object.companyId>> in this step tells the Automation to find the companyId of the Workflow that was just created, and then fetch all the details of that Company - including the values of all the properties/fields on it. We can then reference these in the next step.

The great thing about dynamic references is that the actual values of these references can be different each time the Automation is run, depending on the Workflow, the Company, and the field values at that time.

You'll also see in the screenshot above that we have renamed this step from the automatically assigned random name to "Step 1".

Now we've got the details of the associated Company record, we have the value of its custom Company Scheduling Contact field, and we can copy that into a custom field that we've already created on the Workflow model. We update the newly created Workflow with this value we've just got from its Company.

You can't see it fully in the screenshot above as the names are truncated in the boxes, but in the second line in the "Fields" section above:

Let's go through this step in more detail:

Overall, what this step is saying is we want to update the Workflow that was just created, and specifically we want to populate the custom field on it called "Workflow Scheduling Contact", with the value from the custom field "Company Scheduling Contact" that's on the associated Company record.

Now let's see an example of trigger filtration in action.

In this case, when our "Onboarding" Workflow is completed (archived), and the Company completing it is in a specific segment (Enterprise), we want to automatically change the Company Owner to Bob, who is responsible for Enterprise Companies once onboarded. How can we do this?

We want the Automation trigger to be when a Workflow record with the Template "Onboarding" is archived. We start by selecting that we want the Automation to be triggered when a Workflow is "updated with specific properties".

Then, we can either build the specific trigger criteria directly in the Automation (the preferred option if we won't need to apply these criteria elsewhere), or we can create a Global Filter (in the "Data" Global Tool) with these criteria if we'll want to apply the filter elsewhere. In this case, we'll create them directly in the Automation, as shown in the screenshot below. With these criteria, we specify that the Automation will be triggered when a Workflow of the "Onboarding" Template is archived.

In this example, we also want to apply trigger filtration, so that only Workflows associated with Companies in the Enterprise tier/segment (a custom field) trigger the Automation. In this case, we have already created a Global Filter on the Company model in the "Data" Global Tool, so here we can simply select that, after specifying it's a Company filter.

So putting it all together, our trigger looks like this:

Once triggered, the action we want to happen is that the "Owner" field on the Company is changed to Bob, who's a User (team member) in Planhat. We build the step as follows:

With <<object.companyId>> we specify that we want the Company that's associated with the Workflow that triggered the Automation. "object" is the Workflow record that's triggered the Automation, and "companyId" is a field on it that identifies the Company.

For the Owner field on the Company model, we can select "Owner" from the dropdown on the right, and "Bob" from the dropdown on the right.

That's it - that's the only actual step that we need.

(You may notice that in this example, we haven't changed the step name, so it's showing the random step name of "s-8pc".)

We've seen replacement codes for properties (fields) on Planhat models, but we can also reference dates dynamically in Automations too. One of the key use cases for this is date stamping when something happens.

For example, let's say we have five Company Phases: (1) Pre-onboarding, (2) Onboarding, (3) Ready to Launch, (4) Launched, and (5) Established. We want to measure the time it takes to progress between different Phases, most importantly from (2) Onboarding to (4) Launched, which we are considering our Time To Value (TTV). How can we do this?

We can set up Automations, one for each Phase, that date stamps in a custom field when the specified Phase is entered.

We could then combine this with Formula Fields to look at the difference (in number of days) between pairs of custom date fields. This is very flexible as we can compare any two Phases.

We'll set up an Automation for each Phase we want to date stamp. We want the Automation to be triggered when a Company enters a specified Phase.

As an optional failsafe, we can add trigger filtration that means the Automation will only run if the specified custom field has not yet been populated. This means that this particular Automation will only run once per Company, so if you went back a Phase (maybe accidentally) it wouldn’t overwrite the original date stamp for this Phase.

Finally, let's build the action step.

In this case, <<object._id>> is referring to the Company that triggered the Automation. We're saying that we want to update that Company.

"Onboarding Start Date" is a custom field on the Company model, with a type of either "date" or "date time". You can read more about the difference between these field types here.

<<time.now>> is a dynamic replacement code that saves today's date and current time. (Whether the time is displayed in the field or not depends on whether it's a "date" field or a "date time" field, as discussed here.)

We can then repeat the steps above to create an Automation for each Phase we want to date stamp.

Once we have that data, we can use Formula Fields to count the number of days between any two.

You'll often have dates that you'll want to act in response to, such as the date a contract expires, the last date a subscription can be cancelled, the date of the next QBR, and so on. If all your Companies have these associated dates, it would be a lot of work to manually check all the dates and decide when you should take which action.

Maybe you're already a step ahead, and have at least created a Global Filter or a filtered Page that looks at this date field - for example, a filter for Companies with a renewal date in less than 90 days. If so, great job!

But what comes next? What do you want to happen with these customers? And how should you automate those actions? Here we'll take the common scenarios of creating a task and sending a notification - both actions that can be carried out automatically via Automations.

Let's say for this specific example, our customers are based all around the world, and so different Companies have different fiscal (financial) year end dates. The end of the fiscal year is often when budgets are set, so it's important that our team is in touch with the Company around this time (regardless of when their contract expires), and gives them an indication of what the pricing for the upcoming year is going to look like, making sure the customer budgets correctly for our tool. When the end of the fiscal year is 60 days away, we want to notify the Company Owner (CSM), and also schedule a task for them to get in touch with the customer.

We want the Automation to be triggered when the fiscal year end date is 60 days away. In this example, we already have a custom field that stores the fiscal year end date on each Company.

Creating a Global Filter (in the "Data" Global Tool) could be useful here - we could use it within the Automation but also in various other places in Planhat.

One way to set up this filter would be to first create a Formula Field to calculate the number of days until the fiscal year end date: DAYS_DIFF(<<custom.Fiscal year end date>>, @today). Our filter on the Company model could then refer to this Formula Field:

Once we've set up this filter, we can also use it as our Automation trigger:

Now, when Companies enter the filter (as their fiscal year end date reaches 60 days), this Automation will be triggered.

In this specific example, we don't need to apply trigger filtration, but one example use case could be if we wanted to only apply this particular process to a specific group of Companies - for instance, because we wanted the Automation to trigger for one customer segment, but a Workflow to be applied instead for a different segment.

When the Automation is triggered, one of the actions we want to take place is that a Task is scheduled for the Company Owner to call the Company.

We set up a "Create Task" step like so. The first couple of fields (grayed out) are default and need to be completed; to add the others, keep clicking on "+ Add field".

You may be thinking that there are quite a few fields here, so let's go through each one in turn:

In this example, we also want the Automation to send a notification, to alert the Company Owner. The type/format of this notification can vary - it could be a notification in Planhat itself (showing in the "Notifications" Home feature), an email notification, a Slack notification and/or a desktop notification. The format will depend on how each individual user has set up their notification preferences. Remember that you (and each of your teammates) can configure these for yourselves via the "Notifications" tab of your User Profile, which you can navigate to by clicking on your name in the top right of your Planhat tenant and selecting "Profile".

In this Automation, we create a "Notify User" / "Send Notification" step like so:

The first thing to note is that the "User" in this case is a user of Planhat, i.e. you and your team members. This is different than the "End User" model in Planhat, representing people who are your customers/prospects.

In the "From" part of this step, we specify that the User we want to notify is the one in the Owner field on the Company model. (Other default and custom options are available to choose from via dropdown if required.)

Next, we have the "Message" box (shown in the screenshot higher up), where we can write a custom message for the notification. In this case, we choose "End of fiscal year for Company <<object.name>> is coming up soon!"

Note that there's a replacement code in the message, demonstrating that the notification text can include dynamic data. <<object.name>> is referring to the Company name - remember that the record triggering this Automation is a Company, and "name" is a system field on the Company. Therefore, if the Company triggering the Automation is Intercom, the notification will read "End of fiscal year for Company Intercom is coming up soon!"

In the previous example, the data change that triggered the Automation was on a record of the Company model, and the data on that Company was enough to create the task and notification. But sometimes, you'll need to gather information from other models. What could this look like in practice?

In this example, End Users are classified into types, such as "Champion". We want to post to a public Slack channel when an End User is assigned this label. It could be that the Slack message notifies Marketing that this End User could be a good person to request a review or case study from, for example; or maybe we just want to let the Customer Success team know. Either way, we would like to include the names of the Company Owner and Co-Owner in the message.

We want the Automation to be triggered when the End User has been labelled as a specific type. Let's say we have a custom multipicklist field called "Contact Type" on the End User model. We use this to assign personas to End Users, such as "Technical Contact" or "Standard User". One of the possible options is "Champion", and that's the one we want to focus on here - we want the Automation to be triggered when an End User becomes a Champion. A great way to achieve this is by creating a Global Filter on the End User model (in the "Data" Global Tool), where "Contact Type is any of Champion".

We use this filter as the trigger of our Automation:

As a reminder, Get steps are steps where you want information for an action that's not in the trigger model/record, and so you need to retrieve it separately. This is possible by following relationships between models/records. It's easier to understand when seeing practical examples, and fortunately this Automation contains a few!

We want to retrieve the Owner and Co-Owner of the Company of the End User. Owner and Co-Owner are system (default) fields on the Company.

Our first Get step therefore retrieves the Company of the End User that triggered the Automation.

Because it's a record of the End User model that triggers the Automation, "object" in the replacement codes in this Automation refers to this End User.

We use the replacement code <<object.companyId>> in Step 1 to refer to the system field "companyId" on the End User. In Step 1, we retrieve the Company associated with the End User, including all the fields on that Company - including the system fields "owner" and "coOwner".

Our next Get steps refer to this Company record from Step 1, and retrieve the details of the Owner and Co-Owner, as User records. The reason we need to do this is that the system fields "owner" and "coOwner" on the Company record just contain the Planhat IDs of the Users (you can view this in the Automation logs), and so for our Slack message (in the next step) we need to extract the system fields "firstName" and "lastName" from the User records. (Remember that User is a Planhat model that refers to users of Planhat - i.e. you and your teammates.)

In the replacement codes, we use "Step 1" to refer to the record we retrieved in Step 1, i.e. the Company. Remember that in this example, we renamed the step. You need to use the step name exactly, so if you create another Automation like this and the step name is different, ensure you use that step name in the replacement code (or, of course, rename it to Step 1).

We have now gathered all the data we need for our Slack message.

For the final step, we select "Send Slack message". As we already have our Slack connected to Planhat, we have a dropdown list of Slack channels to choose from.

We can now fill in the "Message" box, similar to the previous example. As before, we can custom-write the text to be included in the message. We use more replacement codes:

<<object.name>> at <<Step 1.name>> is now a Champion. The Company Owner is <<Step 2.firstName>> <<Step 2.lastName>> and the Co-Owner is <<Step 3.firstName>> <<Step 3.lastName>>.

Remember that these replacement codes are dynamic, so they get populated with the relevant data whenever the Automation is triggered. In this case, when we fill in example names, the Slack message posted comes out as:

Adam Smith at Barnett Biosciences is now a Champion. The Company Owner is Ravi Kumar and the co-owner is Katie Cheung.

The text in the "Message" box is completely custom, so if you would like slightly different phrasing than this example, it's easy to change it.

The completed Automation looks like this:

Sometimes, you'll want to take action involving other Planhat models; a typical example is the Opportunity model. Automations are flexible in that they can be used with a wide variety of models (whereas, at time of writing, Workflows - another way you can automate actions in Planhat - are triggered by and apply to the Company or End User model).

There could be various positive signs within your data - for instance, on a Company level, it could be a high Health Score or CSM score, high or increasing usage, having End Users labelled as Champions or Advocates, great average CSAT survey responses, and so on. Using Planhat, you can automatically detect and respond to these, so you don't miss an opportunity for upsell/expansion (or a case study etc.).

Another way Automations can involve the Opportunity model is if they trigger the Automation rather than being in the action/result. For example, when an Opportunity is saved with the status of "lost", you might want a task to be created, for the Company Owner or Co-Owner to review what went wrong and record the details, so you can learn from it and work to prevent that happening again in future. This could be accomplished with a Custom Automation - this is what we'll show in this Automation example.

Here, we will combine some elements from previous Automation examples: gathering information using a Get step, and creating a task. We'll also discuss some of the choices/options in the different steps.

In this case, we want the Automation to be triggered when an Opportunity Status (system field) is set to "lost". As usual, there are different ways we could accomplish this. If we want a Global Filter on the Opportunity model to group these lost Opportunities, we could easily set this up - "Status is equal to lost". We could then use this filter as our Automation trigger.

Alternatively, we could build this rule directly into the Automation trigger - that's what we'll do here.

Here, we've chosen "created or updated" to ensure we include all lost Opportunities.

In this Automation, the record triggering the Automation is an Opportunity. In response, we want to create a task. Who do we want the task Owner to be?

Once we've got the Company information if we need it, we can now create the task step. This will be very similar to what we saw in worked example (D). As before, the first couple of lines (where it's grayed out) are automatically created for us to fill in, and for any others we want, we keep clicking "+ Add field". The completed task step would look something like this: