Product boundaries
Version 6 · Effective September 16, 2026
This document forms part of your agreement with us. It sets the outer edge of what you may put into Spanstead Works: which categories of sensitive information you may store, which are limited to a particular form, and which are not permitted at all. Read it alongside the Commercial Terms, which make a breach of this document a breach of your subscription, and the Privacy Notice.
These limits are deliberate product decisions. They are not a description of what our database happens to accept. With custom fields and file uploads you could technically enter almost anything, which is precisely why the boundary is written down and agreed rather than left to the software.
Because this document forms part of your agreement, the warranties, indemnities and limitation of liability in Sections 12, 13 and 14 of the Legal Terms apply to it. It creates no separate liability of its own, in either direction, and there is one cap across every document between us.
The English text governs. This document may be shown in Spanish or another language as a courtesy. Where a translation differs from the English, the English controls, as Section 19.1 of the Legal Terms sets out.
1. Summary
| Category | Status | Where it may be held |
|---|---|---|
| Social Security and national identity numbers | Prohibited | Nowhere. Your payroll provider is authoritative. |
| Bank-account information | Prohibited | Nowhere. Your payroll provider or your own bank. |
| Medical and disability information | Restricted to outcomes | Work restrictions and accommodation status only. Never a diagnosis or a document. |
| Background checks | Restricted to outcomes | A result and a date only. Never the report itself. |
| Driver licence information | Permitted | Licence details as a worker credential. Images are not permitted. |
| Information about children | Split | Minor employees are permitted with safeguards. Customers who are minors are not. |
| Biometric identifiers | Prohibited | Nowhere, in any form, on any plan. |
| Payment card numbers | Prohibited | Nowhere. Processor tokens and last four digits only. |
Each category below is marked with how the limit is enforced:
Contractual. Stated here. Storing it is a breach of your subscription agreement.
Contractual and detected. As above, and we may run automated checks that flag or quarantine the entry and notify your account owners.
Contractual, detected and blocked. As above, and the product is intended to refuse the entry outright.
2. Social Security and national identity numbers
Prohibited. Contractual, detected and blocked.
You may not put Social Security numbers, ITINs, or equivalent national identity numbers into any field, note, custom field, file, or photograph.
Your payroll provider already holds this information because it must, and it remains authoritative for withholding, filing, direct deposit and pay statements. A second copy here adds nothing and would turn any security incident affecting our database from an operational-data incident into an identity-theft incident carrying notification duties in every state.
Use instead: the payroll provider worker reference on each worker record. This is the link between your record here and your provider, and it is all that is needed for reconciliation and export.
The government identity field on a worker record is limited to a fixed list of document types: driver licence, state identity card, passport, permanent resident card, and employment authorization document. Social Security numbers and ITINs are not on that list, and a value shaped like one is rejected whatever document type you select.
3. Bank-account information
Prohibited. Contractual, detected and blocked.
You may not store account numbers, routing or ABA numbers, IBANs, SWIFT or BIC codes, images of void cheques, or direct-deposit authorisation forms. This applies to workers, customers and vendors alike.
Direct deposit belongs with your payroll provider. Customer payments run through your own connected Stripe or Square account. A vendor payment recorded against a purchase order records that a payment was made and its reference, never the instrument used.
Use instead: a payment method label and reference, such as a cheque number or a processor transaction identifier, that is enough to reconcile the payment and carries no reusable credential.
One consequence is worth stating plainly: expense reimbursement cannot pay a worker directly from inside the platform. An approved reimbursement becomes an earnings line in your payroll export, or it is paid outside the platform.
4. Medical and disability information
Restricted to outcomes. Contractual and detected.
The platform holds the operational consequence of a medical fact. It does not hold the medical fact.
| You may store | You may not store |
|---|---|
| A work restriction and its effective dates, such as no lifting over 25 lb until a given date | Any diagnosis, condition, prognosis, symptom or treatment |
| Accommodation status: requested, active, or ended | The medical justification for an accommodation |
| Leave type at the level scheduling needs, such as medical leave | Doctor notes, fitness-for-duty certificates, FMLA paperwork, or medical exam results |
| Fitness for duty as a yes or no outcome with a date | Genetic information or family medical history, in any form |
| The operational facts of a workplace incident | Injury detail beyond what a workplace safety export requires |
Dispatch and scheduling see the restriction and never the reason for it. This is the separation the Americans with Disabilities Act expects, built into how the product works rather than left to a filing practice.
5. Background checks
Restricted to outcomes. Contractual and detected.
The platform records that a check was run and how you decided on it. It does not hold the report.
| You may store | You may not store |
|---|---|
| Check type, provider name, date requested, date completed | The consumer report or investigative consumer report itself |
| The result, who decided it, and when | Criminal history detail: charges, dispositions, dates, jurisdictions |
| A re-check due date for roles needing periodic screening | Credit history, civil judgments, or bankruptcy records |
| A reference to the report in your screening provider's system | Pre-adverse and adverse action letters and related correspondence |
Holding the report itself would make us a custodian of material regulated under the Fair Credit Reporting Act, with its own disposal rules, dispute handling and permissible-purpose constraints. The decision you reached is what scheduling and job eligibility actually need. The report stays with your screening provider.
Whether you comply with the Fair Credit Reporting Act, including disclosure, authorisation and the pre-adverse action sequence, is your obligation as the employer. This document limits what we hold and makes no representation about your process.
6. Driver licence information
Permitted. Contractual.
Permitted, because vehicle and equipment eligibility depends on it. A licence is held as a worker credential and is used to block assignment where a role requires one.
| You may store | You may not store |
|---|---|
| Licence number, class, endorsements, restrictions, issuing state, issue and expiry dates | Scanned images or photographs of the licence itself |
| The licence as a verified credential, with who verified it | Motor vehicle records or driving abstracts, which are treated as background checks under Section 5 |
| A driver licence as the government identity document on a worker record | Licence information about your customers, which no part of the product needs |
Images are excluded because a photographed licence is a high-value identity document and the only places to put one today are the general file store and field photos, neither of which carries the access controls such a document warrants. This limit will be reconsidered if and when a controlled credential document store exists.
7. Information about children
Contractual and detected. The distinction is whose child.
Minor employees are permitted
Restaurants and seasonal crews genuinely employ 16- and 17-year-olds. Refusing the category outright would not prevent it. It would guarantee that someone enters a false date of birth, leaving a record that is both wrong and non-compliant.
You may store, using the encrypted date of birth on a worker record:
- Date of birth, and a minor indicator visible to scheduling.
- Work permit or age certificate number, issuing authority, and expiry.
- Federal and state hour limits: daily and weekly caps, school-hours restrictions, and night-work cutoffs.
- Prohibited-task indicators, so a minor is not assigned to hazardous work.
Customers who are minors are not permitted
You may not create customer records for minors, or put information about a child into bookings, orders, job records or custom fields. Nothing whatsoever about anyone under 13 may be stored.
Lines of business that require this, including youth sports, tutoring, childcare, camps and school contracts, are outside the scope of this product. Taking that work brings the Children's Online Privacy Protection Act and a patchwork of state student-privacy statutes into a platform designed for neither.
8. Biometric identifiers
Prohibited. Contractual, detected and blocked.
You may not store fingerprints, faceprints, retina or iris scans, voiceprints, hand or palm geometry, gait, or any template or mathematical representation derived from them. Not in a field, not in a custom field, not as a file, not in a photograph, on any plan.
Biometric time clocks are common in this market and their absence here is deliberate. Illinois biometric privacy law carries a private right of action with statutory damages per violation and no requirement to prove any harm, and fingerprint time clocks are the most heavily litigated fact pattern under it. Texas and Washington add enforcement by their attorneys general. No other category in this document carries damages without proof of injury, which is why this one is a flat prohibition rather than a restriction.
Use instead: the fingerprint or face unlock built into your crew phones. The phone releases a session token that is stored on the device; the biometric template stays in the secure hardware of the phone and never reaches our servers. We receive a yes or no and never an identifier. Where you need confidence that the right person clocked in, the platform offers location-stamped and photo-attested punches instead.
9. Payment card numbers
Prohibited. Contractual, detected and blocked.
Card information enters the platform only as what a payment processor returns after tokenising it.
| You may store | You may not store |
|---|---|
| A Stripe or Square token or payment method identifier | The full card number, anywhere, ever |
| Card brand, last four digits, expiry month and year | The security code on the card, which no one may store, including businesses that are fully PCI compliant |
| Cardholder name as returned by the processor | Magnetic stripe or chip data |
| Processor transaction and refund identifiers | The PIN |
This keeps the platform in the simplest PCI compliance category, because card details are captured by the processor and never pass through our servers.
The realistic risk here is not our payment interface. It is a crew member photographing a customer card to run it later and uploading that photo to a job, or someone taking a telephone order and typing the number into an order note. Both bypass every technical control on the payment path, and both put you and us into the scope of the card industry rules. Do not do either.
10. How these limits are enforced
Your agreement. The categories above form part of your subscription agreement. Storing a prohibited category is a breach, curable within 30 days of written notice and grounds for termination if it is not cured.
Product controls. We may reject custom fields whose names indicate a prohibited category, and we may reject values that match the shape of a prohibited category, such as a Social Security number or a card number.
Detection and notice. We may periodically check custom field definitions and their values against the same patterns. Where something is found, we notify your account owners, name the field and the category, and give you a deadline to remove it. We do not delete your data silently. Repeated or uncorrected findings lead to a review of your account.
Two limits on that, stated plainly so you do not mistake any of it for a guarantee:
- We do not scan the contents of files or photographs. The control for uploads is this agreement and the notice shown at upload time.
- We do not monitor your content for quality or accuracy, only for the prohibited categories named here. Nothing in this section is a warranty that prohibited content will be found.
Meeting these limits remains your responsibility whether or not any automated check catches a breach of them.
11. Changes
Where we change this document we will publish the updated version and, where the change materially affects your obligations, ask you to accept it before you continue using the product.