Ticket Templates
Platform

Ticket Templates

Standardize ticket creation with reusable templates. Set default fields, naming conventions, acceptance criteria, custom fields, and validation rules across your organization.

Ticket templates define how tickets are created across your organization. A template sets default field values, naming patterns, acceptance criteria, custom fields, and validation rules. When someone creates a ticket, JuhJuh applies the active template automatically, so every ticket follows the same structure without manual effort.

Why use templates

Without templates, ticket quality depends entirely on whoever is creating them. One person writes detailed acceptance criteria; another leaves the description blank. Templates solve this by encoding your team's standards into reusable configurations.

  • Consistent naming across all tickets in a project
  • Required fields that prevent incomplete tickets from entering the pipeline
  • Acceptance criteria skeletons that guide authors toward structured descriptions
  • Custom fields for metadata your team tracks (environment, component, customer ID)
  • Validation rules that catch formatting errors before the ticket is submitted

Creating a template

Navigate to Organization Settings > Ticket Templates and click New Template.

  1. Name. A unique identifier for this template (e.g., bug-report, feature-request). Must be unique within your organization.
  2. Display name. A human-readable label shown in the template picker (e.g., "Bug Report", "Feature Request").
  3. Description. A short explanation of when to use this template.
  4. Icon and color. Choose a Material Symbols icon and a hex color to visually distinguish the template in lists and dropdowns.

These basics are enough to create a template. The real power comes from the configuration sections below.

Field configuration

Field configuration controls how standard ticket fields behave when this template is active. You can set defaults, make fields required, and add validation.

Each entry in the field configuration maps a ticket field to a set of rules.

Configurable fields

Field Description
title Ticket title
description Ticket description / body
priority Priority level (Highest, High, Medium, Low, Lowest)
ticket_type The ticket's category (Backend, Frontend, Full-Stack, etc.)
issue_type Issue classification (Bug, Feature, Task, etc.)
execution_mode How JuhJuh executes the ticket (Codebase, Standalone, etc.)

Field rules

Each field supports these configuration options:

Option Type Description
default any Value applied when the field is empty at creation time
required boolean If true, the field must have a value before the ticket can be submitted
min_length integer Minimum character count for text fields
max_length integer Maximum character count for text fields
validator string A predefined format check (see validators below)

Validators

Validator Pattern
none No validation (default)
email Must match a valid email address format
url Must start with http:// or https://
alphanumeric Letters and numbers only
slug Lowercase letters, numbers, and hyphens
uppercase Uppercase letters, numbers, and spaces only

Example. A template that requires a title of at least 10 characters and defaults the priority to "Medium":

json { "title": { "required": true, "min_length": 10 }, "priority": { "default": "Medium" } }

Naming conventions

A naming convention is a pattern that auto-generates ticket titles when the creator leaves the title empty. Placeholders are surrounded by curly braces and expand at creation time.

Available placeholders

Placeholder Expands to
{project_key} The project's key (e.g., ACME)
{issue_type} The ticket's issue type
{priority} The ticket's priority level
{date} Today's date in ISO format (YYYY-MM-DD)

Example. The convention {project_key}-{issue_type}-{date} produces titles like ACME-Bug-2026-03-30.

When a naming convention is set and the ticket already has a title, JuhJuh validates that the title starts with the expanded convention pattern. This keeps titles consistent even when authors write their own.

Acceptance criteria skeleton

The acceptance criteria skeleton is a block of text appended to (or used as) the ticket's description. It provides a structured starting point so authors know exactly what to fill in.

If the ticket already has a description, the skeleton is appended after a blank line. If the description is empty, the skeleton becomes the full description.

Example skeleton:

```

Acceptance Criteria

  • Given [precondition], when [action], then [result]
  • Edge case: [describe]
  • Performance: response time under [X]ms

Technical Notes

  • Affected files:
  • Dependencies: ```

Custom fields

Custom fields let you capture metadata that goes beyond the standard ticket fields. Each custom field has a type, and you can mark fields as required or set default values.

Supported field types

Type Description
text Single-line text input
textarea Multi-line text input
select Dropdown with predefined options
checkbox Boolean true/false toggle
number Numeric input

Schema format

Each custom field is defined as a key-value pair. The key is the field identifier, and the value is an object describing the field.

json { "environment": { "type": "select", "required": true, "options": ["production", "staging", "development"], "default": "staging" }, "component": { "type": "text", "required": false }, "is_regression": { "type": "checkbox", "default": false } }

Custom field values are stored as part of the ticket's metadata and are accessible in prompt templates, automation rules, and the API.

External tracker field mapping

If your organization syncs tickets from an external tracker like Jira, you can map template fields to external fields. This mapping tells JuhJuh how to translate incoming data from the tracker into your template's structure.

The mapping is a JSON object where keys are your template's field names and values are the corresponding external field identifiers. This keeps your templates consistent regardless of where tickets originate.

Default template

Each organization can have one default template. The default template applies to all new tickets unless a project overrides it. To set a template as the default, open the template detail page and click Set as Default.

Only one template can be the default at a time. Setting a new default automatically removes the flag from the previous one.

Project overrides

Individual projects can override the organization default. In Project Settings > Ticket Template, select the template you want this project to use.

JuhJuh resolves the active template in this order:

  1. Project override. If the project specifies a template, that template is used.
  2. Organization default. If no project override exists, the organization's default template applies.
  3. No template. If neither exists, tickets are created with no template rules applied.

This means you can set a general-purpose default for your organization and specialize it per project where needed. A backend-heavy project might use a "Backend Bug Report" template while a design project uses "Design Review."

Previewing a template

Before activating a template, you can preview how it applies to sample ticket data. Open a template and click Preview. JuhJuh generates a mock ticket using the template's defaults, naming convention, and acceptance criteria skeleton, then highlights which fields were populated by the template. This lets you verify the template works as expected before it affects real tickets.

How templates are applied

When a ticket is created (from the dashboard, board, or API), JuhJuh resolves the active template and applies it in two passes.

Pass 1: Defaults. Empty or missing fields receive the template's default values. User-provided values always take precedence. The naming convention fills the title only if the creator left it blank. The acceptance criteria skeleton appends to the description. Custom field defaults merge into the ticket's metadata without overwriting existing values.

Pass 2: Validation. After defaults are applied, the template's rules are checked. Required fields must have values. Length constraints must be satisfied. Format validators must pass. If any validation fails, the ticket is rejected with a specific error explaining which field failed and why.

For API consumers, validation failures return a structured error response that includes the template's requirements. This lets agents and integrations retry with corrected data automatically.

Every ticket records which template was applied at creation time. This link is preserved even if the template is later modified or deactivated, so you always have an audit trail of the standards each ticket was created under.

Permissions

Managing ticket templates requires the manage_ticket_templates permission. Organization Owners and Admins have this permission by default. Members can use templates when creating tickets but cannot create, edit, or delete them.

API access

Ticket templates are fully manageable through the API.

Method Endpoint Description
GET /api/v1/orgs/{slug}/ticket-templates/ List active templates
POST /api/v1/orgs/{slug}/ticket-templates/ Create a template
GET /api/v1/orgs/{slug}/ticket-templates/{id}/ Get template details
PATCH /api/v1/orgs/{slug}/ticket-templates/{id}/ Update a template
DELETE /api/v1/orgs/{slug}/ticket-templates/{id}/ Deactivate a template

Filtering. The list endpoint supports ?is_default=true to find the default template and ?q=search to filter by name or display name.

Soft delete. Deleting a template deactivates it rather than removing it. Existing tickets that were created with the template retain their data.

  • Tickets, the work items that templates standardize
  • Projects, where project-level template overrides are configured
  • Boards, create templated tickets directly from the board view
  • Automation, auto-classification and triaging that works alongside template rules
  • Permissions, organization roles that control template management access
  • API, programmatic template management and ticket creation

Previous

Tickets

Next

Boards