Finlay.worksBareBones Ticketing manual

Import Fields

For administrators and import operators. This page describes the columns of a spreadsheet used to load existing records into BareBones Ticketing.

The stock import template is BareBones import template version 1.2, against profile contract 1.2.0. Column names are matched without regard to case, but write them exactly as printed anyway — it is the header the product's own downloadable template uses, and matching it keeps your file comparable with the column guide. This page is the field lookup; the import procedure is elsewhere.

The downloaded template, filled in and re-uploaded unchanged, is expected to pass preflight and preview. If an unmodified template row is reported as missing a required column, that is a product defect worth reporting rather than something to work around in the file.

Before you start

  • Keep source rows, CSVs, JSON, mappings, and error output outside version control.
  • Browser upload accepts at most 5 MB, and at most the configured row limit — 5,000 rows by default.

The stock CSV header

Nineteen columns, in this order:

entityType,sourceRowKey,title,description,departmentKey,departmentName,serviceName,category,requesterEmail,ownerEmail,ticketExternalId,body,participantEmail,participantRole,groupName,accessLevel,plannedAction,plannedTargetKey,notes

Package formats and planned actions

Setting Accepted values
Package format Csv, Json, StagedJson, BrowserParsedCsv
Planned action, at preflight Create, Skip, PreviewOnly
Planned action, at standard apply Create only

Fields by entity

entityType Required fields Optional fields
Department entityType, sourceRowKey, departmentKey, departmentName title, notes
User entityType, sourceRowKey, requesterEmail title, displayName, username, notes
Group entityType, sourceRowKey, groupName title, notes
DepartmentAccess entityType, sourceRowKey, departmentKey, groupName, accessLevel notes
Service entityType, sourceRowKey, title, departmentKey serviceName, category, description, notes
Ticket entityType, sourceRowKey, title, departmentKey, requesterEmail description, serviceName, status, ownerEmail, plannedAction, plannedTargetKey
TicketComment entityType, sourceRowKey, ticketExternalId, body, participantEmail isPublic, plannedAction, plannedTargetKey
TicketParticipantWatcher entityType, sourceRowKey, ticketExternalId, participantEmail participantRole, plannedAction, plannedTargetKey

Fields that are not stock columns

displayName, username, status, and isPublic are not in the 19-column header. Parsers and profile mappings accept them when supplied.

Field Effect when supplied
displayName, username Used when creating a User.
isPublic Used when creating a TicketComment.
status Accepted and staged, but ignored on apply. Standard apply sets the target's initial status. It does not import a source status.

Accepting a field as input does not make it a stock column and does not guarantee it reaches the created record.

Template aliases

The browser parser maps these into the canonical stock fields before preflight.

Template Ticket requester field Comment author field Maps to
Stock and browser requesterEmail participantEmail (already canonical)
Guided Jira reporterEmail commentAuthorEmail requesterEmail, participantEmail
Guided generic requesterEmail authorEmail requesterEmail, participantEmail

Transforms and lookups

Kind Supported values
Transform Trim, ToUpper, ToLower, NormalizeWhitespace, ParseDateUtc, ParseBoolean
Lookup ByKey, ByExternalId, ByNameExact
Date-time custom-field target DateTimeCF.S.<STABLE_KEY> or DateTimeCF.Id.<CUSTOM_FIELD_DEFINITION_ID>

What preflight checks, and what it does not

Preflight refuses a row where a required identity field is missing or blank: requesterEmail on Ticket, participantEmail on TicketComment, or the guided template's alias for either.

A Ready result means preflight raised no blocking finding at all — not only about identity fields. Unsupported formats, entities, or actions, duplicate source keys, values that look like disclosed secrets, and attachment URLs block as well.

Ready does not prove the values will resolve. Standard apply requires each requester or comment-author value to match exactly one active user. A missing, inactive, or ambiguous match fails during apply — possibly after other rows have already been created. The apply ledger and reconciliation report are the authoritative result, not the preflight verdict.

What import does not accept

Not accepted Detail
Secret fields and values Refused.
Attachment binaries Attachment references are metadata only. Files and token-bearing URLs are not fetched.
Live connectors, OAuth, scheduled sync Not provided.
Workflow definitions, CMDB records, passwords, SystemAdmin grants, external participants Not importable.
Update, delete, and reactivate operations Standard apply creates only.