Limits and Scope

This page is the single list of what BareBones Ticketing does not do. Other pages in this manual link here rather than repeating any of it.

Each line describes this version of the product. None of it is a prediction about later versions.

Licensing

There is no hosted version. You run BareBones Ticketing on your own server.
One installation serves one organization. You cannot run several separate companies or clients in one installation.
The organization record is permanent. The first tenant an installation creates cannot be deleted, deactivated, retired, or replaced for the life of that database. Its name and branding can be edited; its existence cannot be undone. Getting a different one means a new installation. See Tenant and organization.
A licence lets the software run. It gives no person access to anything.
Licences cannot share or lend their worker allowance to each other.
The grace period that follows a failed licence check does not raise the worker limit.
When you hit the worker limit, free a seat by removing worker reach — the limit is only ever checked when reach is added, never when it is removed, so the remedy is never itself blocked. In order of certainty:
- Disable the user in User Administration. This always frees their seat, whatever gave them reach.
- Remove a group membership, which frees a seat only if that group was the person's sole worker reach; if another active group or a direct SystemAdmin grant still reaches them, they still count.
- Deactivate or remove the group's department access, or disable the department, which frees everyone whose only reach ran through it.
A licence change that raises the limit also resolves it, but is not required — the count is recomputed live on the next admission check, so a seat freed by any of the above is available immediately.
What the software has stored locally about your licence is not proof that the licence is currently valid. Only a fresh check with Finlay.works is.
Someone who controls the server can work around the licence checks. The product does not try to prevent that.
Downloads are obtained from the Finlay.works customer area against an active licence. This manual carries no download address.

Deployment and availability

The software runs on one server. There is no setup that spreads it across several servers, balances load between them, or keeps a spare running for failover.
No figures are published for how many tickets, users, or simultaneous sessions it handles.
Two health-check web addresses exist for monitoring tools to poll, /health/live and /health/ready. Neither reports on mail, background work, or whether the product is behaving correctly — readiness checks that the database accepts a connection, and that is all.
There are no metrics, no traces, no dashboards, and no alerting. Nothing warns you; you poll, or you read logs.
No recovery targets are committed: not how quickly the system comes back after a failure, and not how much recent data a restore may lose.
No backup schedule, monitoring setup, or alerting setup is provided. Your administrators decide those.
Kubernetes, Helm, Docker Swarm, Nomad, OpenShift, Windows containers, Podman, nerdctl, Docker Desktop on Windows Server, and Compose tools other than Docker's are not supported.
Running the software directly on the host, or building it from source instead of using the supplied container, is not supported.
PostgreSQL is the only supported database. Attachments are stored on the server's own disk; no other storage is supported.
Two operating systems have a full clean-install run against this build: Windows Server 2019 and Rocky Linux 9.7. The others in the supported list should work and are supported, but have not been walked end to end. See Requirements.

Security

BareBones Ticketing holds no security certification — no SOC 2, no ISO 27001, no FedRAMP, and no equivalent.
No independent security test or code audit has been published with this release. Security review is part of development and is recorded in the product's own decision log — see Security in development — but it is first-party, and no report is published.
Step-up — being asked to confirm your identity again before a sensitive change — checks that an administrator is who they say they are. It does not decide what they are allowed to do.
The product does not detect or stop someone who has administrator access to the server, the database, or the stored files. Anyone with that access can change anything.
On a Linux install, membership of the host's docker group counts as that kind of access. It exposes the deployment configuration, container environment, logs, volumes, and runtime secrets to ordinary Docker commands. See Install on Linux.

Regulated use

21 CFR Part 11 is a United States Food and Drug Administration rule covering electronic records and electronic signatures. GxP validation is the documented evidence that a regulated system works as intended.
The product includes approval and electronic-signature features intended for regulated work.
Neither Part 11 compliance nor GxP validation has been completed. Validating an installation is work your organization does, and it has not been done.

Audit history

The audit history is append-only: new entries are added, and the software cannot edit or delete old ones.
Append-only is not the same as tamper-proof. It does not mean the records are cryptographically sealed, nor written to storage that physically cannot be overwritten.
Restoring the database from a backup, or changes made by someone with direct database or file access, are outside that protection and are not detected.
The documented list of audit event types does not prove that every change in the product records an audit entry.
No retention period is committed. Nothing states how long audit history is kept.
An audit export includes a checksum covering the records you selected. It does not prove the export is complete, unaltered, or acceptable as legal evidence.
Redaction hides information from view. It does not delete it. The original is still stored.
Ticket History shows a fixed short list of ticket events. It is not the full audit record.

Service levels

The SLA feature is a timer on tickets that your organization configures. It is not a support promise from Finlay.works.
Each SLA target runs on either 24/7 wall-clock time or a business-hours calendar. The mode is set per target, so first response and resolution can differ on the same policy.
A timer can be paused and resumed. Paused time does not count towards the target, and is excluded from the displayed remaining time, the warning, and the breach alike.
No support response time is promised anywhere in this manual, for any edition or channel.
Support does not include implementation, migration, or validation work in any edition. What each edition does include is in Editions.
Finlay.works does not guarantee its licensing website is always reachable.

Importing existing data

Import creates records. It cannot update, delete, or reactivate them.
If an import fails partway, the records already created stay created. There is no automatic undo of a whole run. The import's own report is the record of what happened.
A Ready result before an import means the check found nothing blocking. It does not mean every value will match a real record when the import runs.
There are no live connections to other systems, and no scheduled synchronisation. Import is a file you upload.
Attached files are not brought across. Only references to them are.
Workflow definitions, asset records, passwords, administrator grants, and external participants cannot be imported.
There is no general-purpose migration from another ticketing system. The Jira and generic templates cover the listed columns only.

Other product boundaries

Replying to a notification email does nothing. Reply-by-email is not available in this release, and an administrator cannot turn it on: the Inbound reply bridge control on Mail Delivery is marked Not enabled for 1.0 and stays disabled unless the deployment's own configuration turns it on, which is not something the product exposes. Even then it needs an approved mail gateway to receive, normalize, sign and post replies back, and no such gateway exists yet. There is also no mailbox polling, POP or IMAP collection, no inbound attachments, and no approve-by-email. People reply in the product.
A ticket can be linked to one project at a time.
Linking a ticket to a project does not reassign the ticket.
Turning off a project does not unlink the tickets already attached to it, and routing rules can still use that link.
The software stops a workflow or status change that would leave live tickets with no move available to them, and it refuses the change before saving anything. What it does not offer is a way to see the shape of a workflow as a whole, a report of tickets that have become stuck, or a tool to repair them. Prevention is the whole of the protection: check a workflow change before you make it, because there is no screen that will find the damage afterwards.
A queue list shows at most 250 rows. There is no next page — rows beyond 250 are not shown at all. Narrow the filter to see them. The figure is fixed in the queue screen and cannot be raised by an administrator.
When a ticket is created, two different rules can each try to set the owner. The software works through the possible owners in a fixed order and takes the first one that applies, so the result is the same every time for the same input. That order is not published as a guarantee, and a later version may change it. Check who the owner ended up as. See Assignment rules.

About this manual

Statements in this manual were checked against the product's source code at the version named at the top, and most were also confirmed on a running installation. Some were checked against source only.
Some lines here are not about how the software behaves. Certification, published test reports, licence commercial terms, and support promises are business statements from Finlay.works, and the source code neither confirms nor contradicts them. Confirm those with your commercial contact.
This manual contains no screenshots.
This manual grants no access, assigns no role, and makes no commercial commitment.