Data can be passed from preventative maintenance (PM) templates or work requests (WR) to unplanned maintenance, also known as work orders (WOs). This function is extremely beneficial because it allows you to create template instructions for unplanned tasks.

We refer to the WO or unplanned maintenance receiving the information as the “child task,” and the task providing the information as the “parent task.”

Passing this data is done by using placeholders, which is the “code” that tells the child task what information to pull from the parent task.

In this article, learn how to create parent and child task templates, and how to pass data between parent and child task templates using placeholders.

Create the Parent Task Template

Locate Placeholders

Create & Connect the Child WO Template with Placeholders

Passing Data from WRs to WOs

The first thing that you need to do is build out your parent task template. As a reminder, the “parent task” is providing the data that will be transferred to unplanned work.

This is a critical step so you can identify what data you want to include in your parent task, and which information you’re going to pass on to the child task.

Both PMs and WR templates can be parent tasks. In this example, we’re doing a weekly PM inspection.

The first instruction asks the user to do a general inspection. The second instruction asks if there are any issues. If there are issues, the user is asked to describe the issue, upload a photo, and start the corrective work order.

Once you’ve created your parent task template, you’ll need to locate and create your placeholders to pass your data to the child task. Placeholders are the “code” that tells the child template what data to pull from the parent template.

Instructions placeholders are most commonly used to do this, but you can also use previous instructions placeholders. We will show you how to find and use both.

Instruction placeholders will look like {{instruction-#}} as shown in the example below.

To find the correct placeholder number(s), go into the parent template and navigate to the instruction you’d like to include. Hover over the placeholder icon and the tooltip will pop up with the correct instruction number.

Be sure to check for the instruction number specifically from the placeholder icon tooltip and not the instruction itself.

For example, the data you’re trying to pass may be within instruction 2, but because it’s a subinstruction under 2, and depending on the order it falls under the instruction, the code may actually be instruction 4, 5, and so on. Failing to check for the instruction number from the placeholder icon could result in the wrong data being passed over.

You can also target off of previous instructions. Unlike the explicit placeholder instruction number, the previous instruction placeholder allows you to use the relative position of the instruction to start WO instruction.

Previous instructions are beneficial when using instruction sets, as their placeholder instruction numbers change when added to a PM or WO template.

You can use {{previous-instruction}} to use the value of the item right before the start WO instruction, {{previous-instruction-2}} to get the value two places back, and so on, up to 10 places back.

We’ll show you how to use instructions and previous instruction placeholders in the next section.

To pass the data from your parent task to the child task, you need to next create the coordinating PM or WO template. Depending on the asset or task, you can make this as specific or broad as you’d like.

To include information from the parent task, add a note instruction that includes a brief description and the desired placeholders in the child task. It should look something like this:

From there, add any additional instructions for the WO template. In this case, we’re asking the user to verify that the issue is resolved. When you’re satisfied with your template, click exit.

Make sure to select the child WO template as the default to be triggered within the parent PM template. In this example, the WO template was named “Resolve Issue” - so it should something like this:

Now that the placeholders are set in place, let’s add some content to the instructions and preview the PM.

Once you’ve set up your WO template, including your placeholders, the work order will look something like this:

The set-up for previous instructions placeholders is not very different from instructions placeholders.

First, let’s explore when you’d use previous instructions in place of instructions placeholders.

Imagine you’re putting together a PM template that includes both new instructions and an instruction set.

You specifically want to pass “Description of Issue” and “Project Number” from the instruction set to the WO template. The placeholder numbers in the instruction set are 2 and 3……

But when the instruction set is added to the PM template, they change to 8 and 9.

By using the {{previous-instruction}} placeholder, you can guarantee you’re pulling the correct data based on its placement within your PM template instead of the placeholder number.

To determine the previous instruction placeholder, find the value from the “Start WO” instruction.

In this case, we know that “Project Number” is the instruction directly before, and “Description of Issue” is two places before, so we’d use {{previous-instruction}} and {{previous-instruction-2}} to pull that information into the WO template.

Now that we’ve determined the previous instruction placeholder, we can add this to our WO template.

When that information is included in the PM:

It will be passed over to the WO:

The functionality of placeholders also works to pass data from WRs as the parent task to WOs as the child task. Passing data from WRs to WOs can provide meaningful context if your unplanned work is disrupting an ongoing project or it derives from a task that requires work from multiple teams.

To set this up for work requests, first, you need to customize your work request template. From the Setup and Configure Work Requests page, choose your desired work request portal and under the Configuration column, click “Customize.”

From the new pop-up, scroll down to Advanced Settings > Use Custom WR Template.

Within this new pop-up, customize the WR template to your liking. In this scenario, we’re adding instructions to validate the work request and start a WO as we did with the PM template.

It should look something like this:

This time, the placeholders are included in the body of the work request template, {{description-of-problem}} and {{picture}}.

Next, repeat the same steps to create the WO child template as shown in the previous scenario. It should look like this:

Once you’ve created the template, click “Exit.” As in the previous scenario, make sure your template is chosen as the default WO template.

Now that it’s set, let’s see how this would look in a work request.

First, the work requestor fills out the form in the portal. Keep an eye on the “description of the problem,” and “picture” as those are what we programmed in our WO template.

This causes the work request to be created.

Since we can see that this is a valid work request, we go ahead and start the work order, which pulls the data as we programmed in the WO template:

And that’s it! Once you understand the principle of placeholders, it’s easy to pass data from a task to additional tasks created inside of it.

How to Create a PM / PM Template

Work Order Templates

Still don’t see what you’re looking for? Check out our YouTube channel for more tips and tricks! You can also reach out to us anytime at support@limblecmms.com.