Importing and Exporting Maintenance Requests

A maintenance request export captures every maintenance request of a site — its fields, its whole conversation, and its attachments — in a single .fpl file. Importing that file into a site recreates the requests there, with their original dates and comments.

Use it to move a site's history to another site, to keep an archive outside the platform, or to bring requests over from another helpdesk or ticket system. For the last case, see Importing Maintenance Requests from Another System, which explains how to write a package yourself.

What a package contains

An .fpl file is a ZIP archive. A maintenance request package holds:

• A manifest.json listing every request of the site with its fields: title, description, notes, resolution summary, state, priority, language, tone, scope, safety hazard flag, reporter, assignee, supervisor, watchers, unit, tags, CC addresses, feedback, and dates
• Each request's comments, in order, with author and time
• All attachments — files on the requests and files on their comments — in an attachments/ folder

People are written as email addresses, and units and tags as names, never as internal IDs. That is what lets a package from one site be imported into another.

Requests that are not assigned to any site are not part of a site's export.

Exporting maintenance requests

1. Open the site from the dashboard
2. Navigate to Settings > Import / Export > Maintenance Requests
3. In the Export Maintenance Requests card, click Export
4. Wait for the Export ready for download message. The export runs in the background, so you can keep working, and large sites can take a while
5. Click Download

The downloaded file is named tickets- followed by the date, for example tickets-2026-09-29.fpl. The Download button also appears when you open the page if the site has been exported before; it always gives you the latest export. Run Export again to refresh it.

The download link is valid for 15 minutes. If it has expired, click Download again to get a new one.

Files over 100 MB are left out

A package can hold single files up to 100 MB. Attachments larger than that are left out of the package, and the page tells you: a message titled Some attachments were left out lists the requests and file names. It stays on screen until you close it, so you can copy the names. The requests themselves are exported in full; only those files are missing.

Export errors

The export fails, with a readable message on the page, if the site holds more files than one package can carry (the message says how many), if the request list alone is over 100 MB, or if all files together are over 10 GB. The previous export is kept when a new one fails.

Importing maintenance requests

1. Open the target site from the dashboard
2. Navigate to Settings > Import / Export > Maintenance Requests
3. In the Import Maintenance Requests card, click Upload .fpl Package
4. Step 1 — Upload: in the Import Maintenance Requests window, click Select .fpl Package or drag the file into the window. The file is uploaded, then checked automatically
5. Step 2 — Preview: while it shows Checking package..., the platform reads the whole package and validates it without writing anything. The result lists:
   • Maintenance requests to import, and Already imported, will be skipped when some are already on the site
   • Comments and Attachments that will be created
   • New tags: tags in the package that do not exist on the site yet and will be created
   • Unknown units (left empty): unit names the site does not have
   • People not found in this site: email addresses that match nobody on the site, each with the role it had (reporter, assignee, supervisor, watcher, comment author)
6. Click Import. Use Back to choose another file instead
7. Step 3 — Import: the import runs in the background (Importing maintenance requests...) and finishes with Import Successful and the counts Maintenance requests created, Comments created, Attachments uploaded, and Skipped (already imported). Click Close

The Import button stays disabled if the package is empty (This package contains no maintenance requests.) or if everything in it is already on the site (All maintenance requests in this package are already imported.).

If the package is invalid, Step 2 shows a red error instead of the list and nothing has been written. Fix the package and upload it again.

Imported requests get new request numbers from the site. The numbers from the source system, if the package has any, are only informational.

Only an admin or manager of the site can import or export. The Maintenance Requests page appears only on sites where the Maintenance Requests feature is turned on.

After a successful import

The uploaded package is deleted from the platform once the import succeeds. A package that failed, or that you only previewed, stays until you retry or upload another.

How people are matched

The platform matches people by email address, ignoring capitals, against what the target site already knows. Nobody is invited or created.

A reporter or comment author kept as text still shows on the request with the name from the package, and if staff later comment, the reporter's email address receives the usual notification.

The Preview lists everyone who was not found under People not found in this site, so you can decide before importing whether that matters. To have an assignee or watcher carried over, add them as a user of the site first and preview again.

How units and tags are matched

• Units are matched by name, ignoring capitals and spaces around the name. A request whose unit is not found is imported without a unit, and the name is listed under Unknown units (left empty)
• Tags are matched by name, ignoring capitals, against the site's existing request tags at any level. Tags that do not exist are created as new top-level tags, once per name, and listed under New tags

Re-importing is safe

Every request in a package carries an externalId. For a package exported from the platform this is the request's original identifier, and it is kept when a package is exported and imported again, so the chain export, import, export, import keeps recognizing the same requests.

On import, a request whose externalId already exists on the site is skipped and never changed. Importing the same package twice creates nothing the second time, and re-running an import that stopped part-way only adds the requests that are missing. The Preview and the result show how many were skipped.

Because existing requests are never updated, importing a corrected package does not change requests that were already imported.

Imported history stays quiet

Imported requests are historical records, so importing them does not set anything in motion:

• No emails and no notifications are sent to reporters, assignees, watchers, or anyone else
• No Fia runs: Fia does not classify the imported requests or assign them to a site
• Resolved requests never auto-close: a request imported as resolved is not closed by the site's automatic closing of resolved requests, so no closing email goes out
• Reminders start after the normal quiet period: imported open requests are treated as if they were just touched, so inactivity reminders only begin once the site's usual quiet period has passed after the import
• Original dates are kept: created, updated, resolved, and state-change times come from the package, and importing comments does not change a request's updated time

After the import, imported requests behave like any others. When staff comment on one later, the normal notifications go out, including to a reporter who is kept as text and to CC addresses.

The change history (the log of who changed what), links to tasks and work orders, and Fia's own analysis of a request are not part of a package.

Limits and file names

An accepted file name uses letters (including ä, ö, õ, ü), digits, spaces, and the characters _ - . ( ), and ends in .fpl, in any case (.FPL works too). It cannot contain slashes. Names such as Tööd 2026.fpl and a browser's tickets-2026-09-29 (1).fpl are fine.

Error messages

Errors are shown in the wizard in plain language. The most common:

If an import fails because of a platform problem rather than a bad package, it is retried automatically and continues where it stopped, because requests that were already written are skipped. While a retry is pending, the window shows Import failed on attempt {attempt} of {maxAttempts} — retrying in about a minute., with the real numbers in place of the braces. If the last attempt fails too, the error reads like this, and importing again continues from there:

Import stopped at maintenance request 401 of 1200: 400 of them are already on the site. An unexpected error occurred and has been logged — running the import again continues from here.

Access and API keys

• In the app, importing and exporting is for site admins and managers
• Scripts can use an API key. Exporting needs the Maintenance requests permission at read level (ticket:read); uploading, previewing, and importing need read & write (ticket:read_write). Either permission can read the state of these jobs. See API Keys

The endpoints, the package format, and a worked example are in Importing Maintenance Requests from Another System.

When it is most useful

• Moving a site's history: export from one site and import into the site that takes over its operation
• Migrating from another system: bring years of tickets, with comments and photos, into Fentrica and switch over without losing history
• Archiving: keep a dated copy of a site's requests outside the platform

Next steps