Why repetitive work deserves better than manual effort

[#1]

Why repetitive work deserves better than manual effort

In nearly every organization, teams deal with recurring processes, projects, and tasks – it’s simply part of how work gets done.

• In HR, it’s employee onboarding and offboarding.
• In Finance, resolving invoice disputes or clarifying billing details.
• In IT services, deploying similar solutions for multiple clients.
• In software companies, recurring release steps, backlog refinement, or sprint rituals.

These activities bring real business value, but the operational side is often repetitive. In Jira, this typically involves recreating very similar issues and subtasks repeatedly. And let’s be honest – doing that manually each time is time-consuming, error-prone, and rarely adds value.

To maintain quality and consistency across teams, using templates makes sense. They help standardize processes, remove the need for manual task creation, and ensure nothing gets missed.

A template doesn’t need to be complex. Sometimes it’s a full hierarchy (Epic → Tasks → Subtasks). Other times, it’s just a single recurring issue where only the version, assignee, or short description changes. Once such a structure exists, cloning it saves hours and keeps teams aligned.

And the best part? You can build these templates using only Jira’s native features – no plugins required.

A use case everyone understands: onboarding a new employee

Let’s use a familiar process: employee onboarding. It’s a perfect example of a workflow that involves multiple teams, touchpoints, and dependencies.

• HR oversees hiring documentation, contracts, benefits, and learning & development.
• Health & Safety ensures that the required training is completed.
• IT Support prepares equipment, accounts, and system access.
• Finance handles payroll setup and legal compliance steps.

There are so many actions, people, and places where things can fall through the cracks unless the process is structured and repeatable.

In this example, I’ll show how to build a cross-department onboarding template using Jira’s native features and then clone it efficiently to maintain service quality over time.

Before we jump in, let’s look at how to define the right task structure.

Defining the structure

The first step is outlining the full scope of work. List all necessary activities and assign the team or department responsible for each. The easiest and most reliable way to do this is to start from real past cases – when you begin a standard process, it’s rarely the first time it has happened.

You can also reference internal procedures or checklists – most companies already have them in some form, so they’re a great source of truth.

Using our onboarding example, the task structure might look like this:

HR DEPARTMENT

LEARNING & DEVELOPMENT DEPARTMENT

Define agreement details (Job position, Type of contract, Salary, Working time, Start date, Employment percentage) Medical checks: Issue referral for pre-employment medical examination Verify medical clearance Employment documentation: Prepare the contract and other hiring documents Send and collect signed documents Pass documents to accounting Announce the new hire on the intranet Assign a buddy or mentor

Trainings: Company introduction, organizational culture, values Internal policies, benefits overview, and organizational structure General training (e.g., compliance, ethics, cybersecurity) Access to e-learning platforms

HEALTH & SAFETY DEPARTMENT	IT SUPPORT DEPARTMENT
Initial safety training (general instruction)	Initial safety training (general instruction) Create an account in the HR system Create an email account Create a company account/access Prepare and issue a laptop Order and issue a mobile phone (optional) Print and issue an ID badge

FINANCE & PAYROLL DEPARTMENT

Payroll setup Registration for the pension fund Set up access to benefits (e.g. sports cards, medical plans, additional perks) Register in the travel expense system (if applicable) Set up bank account details in the payroll or payment system

Creating a Template Structure in Jira

Now that the list of activities is ready, it’s time to convert them into work items in Jira and assign them to the right projects and hierarchy levels.

To build effective templates, I recommend using a master Epic with child issues assigned to the appropriate Jira spaces. The Epic acts as a “container” that groups all activities related to the process you want to template.

Choosing the right place for the Epic

In our onboarding example, the process is initiated by HR. That’s why the Epic should be created in the HR space. The name could look like this:

Epic: [TEMPLATE] New Employee – Hiring & Onboarding

I use the [TEMPLATE] prefix in the Summary field of every issue that is part of the template. This lets you clearly distinguish between real tasks and template items.

Of course, you can choose any prefix that works for your organization – for example:
[PATTERN], [MODEL], [LAYOUT], [FRAMEWORK], or anything else that indicates the issue is only a template and should not be planned or executed.
The most important part is consistency – I’ll explain why later.

For now, let’s focus on the structure itself. Content configuration will be covered in a later section.

Creating tasks and sub-tasks under the right spaces

Once the Epic is created, we add tasks and subtasks in the correct Jira projects (spaces). Each of these items must be linked to the master Epic:

Alignment with existing configurations

In my example, I recommend using Tasks under a single Epic, but if your projects use other work types – such as “Request new hardware”, “Access setup” or “New joiner” – feel free to use them. The template should match your workflows, not the other way around.

This approach gives you full flexibility and compatibility with department-specific processes. You don’t need to adapt your procedures to the tool – the tool should support how your teams work.

Creating template-work items content

Once the template structure is ready, the next step is to define the content of each work item. In most cases, instructions, descriptions, or default field values are reusable and similar across iterations, so it makes sense to configure them directly inside the issue.

Let’s take one of our earlier example tasks:

Task: [TEMPLATE] Prepare employment contract and required documents

Imagine that your company hires employees in multiple regions, each with its own legal and administrative requirements. There are two good ways to reflect that in a template:

✅ Option 1 – Use custom fields per region

Create dedicated custom fields or checklists for each location (e.g. UK, US, DE, FR). This helps segment responsibilities, making it easy to filter or automate later.

✅ Option 2 – Use a structured Description field

You can include region-specific sections directly in the Description.

Here is an example of how the content may look:

Depending on your setup, you may use a checklist format, bullet points, or a table. The exact layout should reflect how your HR team already works.

✅ Description vs. checklist vs. form fields

A checklist is a great solution when steps must be tracked individually, but it is not mandatory. You can also write a short instruction-style description, like in the example below:

There’s no single correct approach – the content must align with your company's rules and compliance requirements.

If it’s helpful, you can also attach a file with procedures, document templates, or email patterns directly to the template work item.

Using other fields in the template

Beyond the Description, you can also populate structured fields that are always relevant:

Examples:

• Task: [TEMPLATE] Prepare and issue a laptop → Team: Device Management
• Task: [TEMPLATE] Order and issue a mobile phone → Team: IT Procurement
• Task: [TEMPLATE] Print and issue an ID badge → Team: Security

That makes filtering easier and automatically routes the work items to the correct people.

If your organization is small and the same person always performs some activities, you can also define the Assignee directly in the template.

In addition, you may configure other useful and repeatable fields, such as:

• Watchers
• Attachments (e.g. procedures, document templates)
• Estimation
• Components
• Start date / Due date
• Any custom fields used in your workflows

Adding these fields upfront enables teams to plan more effectively, maintain issue consistency, and minimize the need for manual updates after cloning.

Template Custom Field

Before you start:
If you work in a company-managed project, the configuration described below must be done by someone with Jira Administrator permissions.
In a team-managed project, the team can do the setup directly.

To make template issues easy to identify, filter, and exclude from normal work views, it's worth adding one extra custom field called “Template”.

I recommend using the Checkboxes field type with a single option: “Yes”.
When configuring the field, set the Search Template to “Multi-Select Searcher”.
Why is this important?
Because you won’t be able to search or filter your templates properly in Jira with any other search template.

Where to place the field

Once the field is created, add it to the relevant screens. It doesn’t need to appear at the top – placing it at the bottom keeps it out of the way during normal task creation. This field should not be required.

Why only one option?

I suggest using just one checkbox option: “Yes”.
The logic here is simple:

• Regular issues don’t need to be marked.
• Only templates should be tagged.
• You avoid forcing users to click anything while creating normal tasks.

Of course, you could also add a “No” option and make the field mandatory. However, that only creates unnecessary work for users and adds no real value, because everything is “not a template” by default unless marked otherwise.

What are the benefits of marking templates?

Once your template issues are tagged with this field, you can:

• Quickly search or filter them using basic search or JQL
• Exclude templates from boards and backlogs using a simple query
• Build dashboards to show only template structures in specific projects
• Prevent tools like Rovo from treating templates as active work items
• Group and manage template libraries across teams

Custom naming

Feel free to use something else if the word “Template” doesn’t fit your company’s terminology. For example:

Pattern | Model | Framework | Standard | Blueprint | Guide | Mold | Layout

Choose whatever feels natural in your organization – the field name won’t impact functionality.

Change the Status of Your Template Work Items

To prevent template issues from appearing in active backlogs or boards, it is important to place them in a status that belongs to the DONE category.

Why this matters:

• Templates should not be treated as deliverables.
• Jira boards and backlogs typically display only issues in TO DO or IN PROGRESS categories.
• If a template stays in an open status, it may appear in sprint planning, kanban columns, or reports.

By moving templates to a DONE-category status (e.g., Done, Closed or your custom equivalent), you ensure that:

✅ They do not appear in team backlogs
✅ They are not assigned to sprints by mistake
✅ They don’t clutter active boards
✅ Planning and reporting stay clean

In other words, marking template issues as Done doesn’t mean the item is “completed” – it simply removes them from the delivery flow and keeps them out of the way until you clone or reuse them.

If needed, you can reopen the issue when using it. However, in most cases, the cloning process automatically creates a new issue in the correct starting status.

Creating a Dashboard to Present Your Templates

If you have already created a Template custom field and tagged your template work item, you can now build filters and dashboards to easily manage and visualize them.

Step 1: Create a filter presenting your templates

Before adding anything to a dashboard, you must build a filter that lists your template issues.

In most cases, showing all issues marked as templates in one global view doesn't make sense.
It’s much more useful to focus only on Epics, since the Epic summary usually provides the best overview of the template’s scope.

Of course, if your templates are more granular (for example, individual Tasks or Sub-tasks), you can adjust the filter accordingly.
This example will focus on Epics at the master template level.

Go to Filters → Search work items, and you can choose one of three methods:

🔹 Option 1: Basic search

1. In the Issue Type dropdown, select Epic.
2. In More fields, find Template, and check Yes.

🔹 Option 2: JQL search

Enter the following query:

type = Epic AND "Template[Checkboxes]" = Yes

🔹 Option 2: JQL search

Enter the following query:

type = Epic AND "Template[Checkboxes]" = Yes

You can also extend your filter by adding additional conditions, such as specific projects, teams, or components.

Once your search results look correct, click Save as filter, give it a clear name (e.g., All Template Epics), and decide whether to keep it private or share it with your team.

Step 2: Create a dashboard

• From the left-hand sidebar, go to Dashboards.
• Click the “+” icon (Create dashboard). 
• Add a gadget – select Filter Results. 
• Choose the filter you just created and configure display options (columns, number of results, sorting) as needed. 
• Save the dashboard.

You’ll now have quick and consistent access to all your templates directly from your dashboard.

For company-managed projects, it’s best if the filter and dashboard are created by an administrator and shared across the organization. This ensures the template experience remains consistent for everyone and prevents multiple users from duplicating the same filters and dashboards.

Template cloning

Once your templates are prepared and shared across teams, it’s time to start using them.
To transform templates into ready-to-use work items, you need to clone them – ideally with their entire hierarchy.

There are two main ways to do this in Jira:

1. Use the native Jira clone feature
2. Use a dedicated Marketplace app, such as Clone Expert for Jira Templates, Epics, and Issues (Work Items)

A note on automation – building custom Automation for Jira rules with a manual trigger from a work item might be tempting. However, based on experience, the results are usually similar to what the native clone feature already provides – and maintaining such automation can quickly become complex.

If you’ve built an automation that effectively clones entire hierarchies, feel free to share your approach in the comments – I’d love to learn about other creative ways teams handle this!

Through the Native Clone Feature

Jira’s native clone feature is available on any work item – you can find it under the Actions → Clone option.

When you select Clone on your Epic template, Jira opens a form that lets you customize how the clone is created.

Step 1. Update the summary

The first field is Summary.
By default, Jira adds the prefix CLONE – to the issue summary.

I recommend removing that prefix and replacing the [TEMPLATE] tag with the new joiner’s name.
For example, your new Epic could look like this:

[Jon Smith] New Employee – Hiring & Onboarding

Step 2. Set the assignee

The Assignee field can be left empty or set to the supervisor responsible for the process.
Remember – an Epic acts mostly as a container for related tasks.
If you want someone to oversee the onboarding, assign it to the manager.
Otherwise, leave it blank and let each team manage their child tasks.

Step 3. Reporter

It’s best to leave the Reporter field as it is.
The person performing the clone is responsible for creating the right set of issues for the new hire, so keeping that person as the reporter maintains transparency.

Step 4. Include options

In the Include section, several checkboxes control what gets cloned:

OPTION	RECOMMENDATION	EXPLANATION
Attachments	✅ Select it	If attachments exist in the template, they’re likely essential reference files.
Child work items	✅ Select it	This ensures the entire hierarchy – from Epic to Sub-tasks – is cloned.
Links	✅ Select it	Keeps references to related issues. Useful if your templates are connected to external or parent items.
Clone sprint value	❌ Do not select	Sprint values usually refer to past work. New issues will appear in the backlog, ready for proper sprint assignment.

Step 5. Cloning result

Once cloned, Jira creates all work items (from Epic to subtasks):

• In the same project as the original template
• With all attachments copied
• With all child issues (Tasks and Subtasks)
• With links preserved
• With the selected Reporter
• With summaries prefixed by CLONE –
• With identical content and field values as in the template

For example, cloning the HR onboarding Epic would produce:

All tasks from other spaces (IT, Finance, Learning & Development, etc.) would be cloned in the same way.

Step 6. Adjust cloned content

After cloning, the reporter or project owner should update the new issues:

• Remove the CLONE – prefix
• Replace [TEMPLATE] with the new employee’s name (e.g., [Jon Smith])
• Update descriptions with specific details – start date, department, team, etc.
• Remove tasks that are not applicable (e.g., ordering a mobile phone)
• Adjust due dates or timelines
• Set correct assignees
• Remove “clone” issue links to prevent templates from being connected to all clones.

Step 7. Evaluate if native cloning is sufficient

As you can see, the number of manual adjustments can be quite large.
The native clone feature is helpful but not very flexible – especially if you need to modify content, reassign teams, or adjust field values before cloning.

I recommend using the native option only for simple templates that require minimal updates after cloning.
For more complex, multi-project structures, a dedicated app (such as Clone Expert for Jira Templates, Epics, and Issues) offers much greater efficiency and control – which we’ll explore in the next chapter.

Through Clone Expert for Jira

Once the Clone Expert for Jira app is installed, you’ll find an additional option under the Actions → Clone Template menu on any work item.

When selected, this option opens a cloning window with a preview table displaying the selected Epic and all of its child issues (down to the Subtask level).

The preview table allows you to update any field before cloning – for example, Summary, Description, Hiring Date, Manager, or Region.
All changes you make here will apply to the cloned work items, while the original template remains untouched.

To speed up the process, consider using the bulk options in the column header.

Step 1. Update the Summary fields (bulk replace)

Start by updating the Summary column using bulk options.
The fastest way is to use Find and Replace to remove the [TEMPLATE] prefix and replace it with the new joiner’s name – for example:

Replace [TEMPLATE] with [Jon Smith]

Step 2. Update dates and assign managers

In the Hiring Date column, you can use the Bulk → Overwrite Date Value option to apply the same date to all issues in the table.

Then, in the Manager column, you can specify who will supervise the new hire.
In my example, this field is a text field, so the manager’s name can be entered manually – for instance, Emily Davis.

However, you can also configure this field as a user picker.
In that case, instead of typing, you can select a Jira user directly from the list and apply them to all relevant work items using the bulk options.
Both approaches work – the difference depends on whether the manager should be a Jira user or just referenced by name.

Step 3. Add regional context

In the Region column, select the appropriate country or location in the bulk update window and apply it to all work items.
This helps tailor cloned issues to regional onboarding requirements.

Step 4. Customize or exclude specific items

You can freely adjust any other fields or fine-tune specific issues in the table.
If a particular item is not needed (for example, Order and issue a mobile phone), simply uncheck it to exclude it from the cloning scope.
Conversely, if something is missing from your structure, you can add a new work item directly in the preview table – it will be created during cloning.

Step 5. Confirm cloning components

Before running the clone, review the configuration to ensure that all necessary elements are included: Sub-tasks, Attachments, Watchers, and Issue links.

These components guarantee that your new work items maintain all key connections from the template.

Step 6. Run the clone

When everything looks ready, click the Clone button located below the preview table.

Step 7. Review the results

Once the cloning process finishes, you’ll receive:

• All selected work items cloned (from Epic to Sub-tasks) according to your chosen scope
• Issues created in the correct projects/spaces
• Attachments copied
• Links preserved (as configured)
• Summaries already customized (no CLONE –,  [TEMPLATE] replaced with the new joiner’s name)
• Field values updated exactly as defined in the preview table (e.g., dates, manager, region)
• Ready-to-plan items visible in the right team backlogs

In other words, everything is tailored right away, properly structured, and ready for action.

Clone Expert gives you full control over the cloning process before it happens – reducing manual adjustments, preventing data cleanup afterward, and letting you deliver perfectly prepared issue hierarchies in just a few clicks.

In short: you get the same structural results as native cloning (attachments, children, links, reporter), plus your edits are applied before creation – so there’s no cleanup of CLONE – prefixes or manual field changes afterward.

Summary

Using Clone Expert for Jira allows teams to manage templates more efficiently by editing and validating all details before cloning.
The preview table provides a clear view of the entire hierarchy, supports bulk updates, and helps ensure that every field, attachment, and sub-task is properly configured.
This approach minimizes manual adjustments after cloning, keeping the resulting work items consistent and ready to plan.

For more information and resources, see:

Tool overview and description User documentation Clone Expert for Jira on the Atlassian Marketplace Book DEMO

Wrapping Up

Creating and maintaining templates in Jira – even using only native features – can significantly simplify how teams handle repetitive processes. Whether it’s onboarding a new employee, managing release activities, or coordinating routine financial reviews, templates help keep work consistent, organized, and efficient.

Starting with native Jira functionality is often enough for simple workflows: you can build clear Epic-Task-Subtask structures, mark templates with a custom field, and keep them out of your backlog by setting their status to Done. Dashboards and filters then make it easy to manage and share these templates across teams.

As your structures grow in complexity or you need to control every detail before cloning, dedicated solutions like Clone Expert for Jira can further streamline the process, providing visibility, flexibility, and accuracy from the start.

The key takeaway is simple:
Templates are not about automation for its own sake – they’re about consistency, quality, and saving time for the work that really matters.