Acceptable Use Policy

Version 1.0 · Last updated 6 September 2026

1. What this policy is, and who it binds

Field 2 Service is field-service management software. You — the business with the subscription — decide what information goes into it and what is done with it. We hold and process that information on your instructions, and nothing else. This policy sets the outer boundary of those instructions: the things we will not process for you, whatever the software would technically allow.

It binds:

• your account and every user account inside it, including administrators, office staff and field engineers;
• anything acting under your API tokens, webhooks or integrations;
• anyone you invite into your workspace, and anyone using your customer portal or public booking page.

You are responsible for all of it. If a user of yours breaks this policy, that is your breach, not theirs. If you resell or provide access to the service to another business, you are responsible for their compliance as well.

By accepting our Terms of Service you accept this policy. If you cannot comply with it, do not use the service.

---

2. Your obligations as the controller of your data

You are the data controller for the personal data you put into the service — your customers, your leads, your staff. We are your processor. That means several things are yours to do, and cannot be ours:

1. Hold a lawful basis for every category of personal data you store and every use you make of it.

The software does not record why you hold a person's data, and cannot decide it for you.

1. Give your own privacy notice to the people whose data you enter — your customers, your leads and your staff. They are entitled to be told who holds their data and why, and that is your notice to give, not ours.
2. Keep your instructions lawful. If we believe an instruction you give us would breach data protection law, we will tell you and we may decline to act on it.
3. Answer your own customers' data protection requests. When one of your customers asks us directly for access, correction or deletion, we will not answer as though the data were ours. We will tell them to contact you, and we will tell you they asked.
4. Keep your records accurate and current, and remove what you no longer have a reason to hold.

1. ⭐ Know your own breach clock, and tell us the moment you suspect one. When we become aware of a breach affecting your data we notify you immediately, with no risk filter applied at our end, and in no event later than twenty-four hours — we do not decide whether it is serious enough for you, because the test that applies to you depends on where your customers are and the tests are not the same. Section 7 of the Data Processing Agreement sets out that rule, and section 7.4 of that Agreement records what our detection actually consists of. Your side of it is to know your own deadline and to tell us fast — if you see something in your activity log that concerns you, we would far rather hear about it early and be wrong.

---

3. Prohibited uses

You must not use the service, or allow it to be used, for any of the following.

3.1 Unlawful and harmful use

• Anything that breaks the law in Ireland, in the United Kingdom, or in any country where you operate or where the people whose data you hold are located.
• Storing, sending or distributing content that is defamatory, harassing, threatening, obscene, hateful, or that incites violence.
• Infringing anyone's intellectual property, trade secrets, confidentiality or privacy rights.
• Impersonating any person or organisation, including Field 2 Service, or misrepresenting your affiliation with one.
• Fraud, deception, phishing, or misrepresenting who is sending a message to a customer.
• Uploading or transmitting malware, ransomware, or any code intended to damage or disrupt a system.

3.2 Special-category and criminal-offence data — prohibited unless we agree in writing

You must not enter special-category personal data into the service unless you have first obtained our written agreement. That means data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data used to identify someone, data concerning health, or data concerning a person's sex life or sexual orientation.

You must not enter criminal-conviction or criminal-offence data — including data about alleged offences, proceedings or security-clearance outcomes — unless you have first obtained our written agreement.

This matters in practice, and it is the clause most likely to be broken by accident. A field-service system attracts health and vulnerability information without anyone intending it: a note on a job saying a customer is housebound, has a carer, is on oxygen, has a disability that affects access, or "do not call before 11am — night shift, on medication". A photo attached to a job can show the same thing.

If your work genuinely requires that kind of information — for example, an accessibility or safeguarding note that a lone-working engineer needs before a visit — contact us at hello@field2service.com before you start storing it. We will agree in writing what may be held, where it may be held, and on what basis, and record it as an agreed instruction. Do not decide unilaterally that a note is harmless.

You must also not use the service as a personnel or occupational-health record for your own staff: sickness records, medical certificates, disciplinary files and similar belong in an HR system, not here.

3.3 Children's data

The service is not designed for, or directed at, children, and is not intended for use by anyone under 18. It performs no age verification and collects no date of birth anywhere — so it cannot help you tell an adult from a child, and you must not assume that it does.

You must not use the service to build records about children. Where a child's details are unavoidably incidental to work you do for an adult — a name on a household record, for example — keep it to the minimum and hold it under a lawful basis of your own. Do not rely on a child's own consent as that basis: the service cannot verify age, cannot verify that a parent or guardian authorised anything, and keeps no record that would let you demonstrate either.

⚠ And it gets stricter, not looser, outside Europe. Where you serve customers in India, the forthcoming Digital Personal Data Protection Act will require verifiable consent from a parent or guardian before any personal data of anyone under eighteen is processed, with no minimum threshold, and will prohibit tracking, behavioural monitoring and targeted advertising directed at children. The service cannot deliver any of that — no age gate, no parental-consent capture, no way to segregate a child's record — so if that regime applies to you, the control has to sit in your process, before the data reaches us. Quebec sets its threshold at 14, Maryland bans targeted advertising to and the sale of the data of anyone under 18, and three other states require consent in a band of their own — New Jersey 13 to 17, Minnesota 13 to 16, Montana 13 to 15. None of those numbers is enforced by the software.

3.4 Marketing, email and SMS

The service can send email and SMS to your customers. Those are your messages, sent by you, under your sender identity, and you are the sender in law.

You must not:

• send unsolicited direct marketing by email or SMS to anyone who has not consented to receive it, where consent is required;
• send marketing to anyone who has told you to stop, by any route;
• send marketing without a valid, identifiable sender and a working way to opt out;
• send bulk or repetitive messages to people you have no existing relationship with, or use the service as a bulk-messaging platform rather than as part of running field work;
• send content that would be unlawful for you to send directly.

Understand what the software does and does not do for you here. Each customer record carries an email-contact and an SMS-contact flag. Since 6 September 2026 those flags are honoured on every message the service sends that customer — automations, invoice reminders, appointment notifications, review requests, messages the AI assistant sends, and the direct "Send quote" and "Send invoice" actions. The decision is made in one place and applied inside the two components that actually send, so nothing in the product can go round it, and a suppressed message is recorded as blocked rather than as a delivery failure.

They are still not a consent-management system:

• they are three-state — may contact, must not contact, and not recorded. A customer created through any route other than the customer portal records not recorded: nobody asked them. There is no company setting that turns that into may contact, and there deliberately never will be. A not-recorded preference permits only the transactional documents the customer is already entitled to under their contract, and blocks automation and marketing;
• so a flag reading may contact records that somebody in your business set it, not that you obtained consent that meets Article 4(11);
• there is no separation, in the preference, between marketing and transactional messages — one pair of flags governs everything, so a customer cannot opt out of marketing while keeping appointment reminders. The service classifies each message it sends as transactional, automated, marketing or account-security when it decides whether to send, but that classification is ours, not something the customer can set;
• one class of message a flag never stops: a message about the customer's own access to your customer portal that they asked for in that request — the password-reset link they requested, and the confirmation after they set their own password. An opt-out must not lock a person out of their own records;
• every change to a flag is recorded — the old and the new value on each channel, where the change came from, who made it and from which IP address. That is evidence that a preference moved. It is not evidence of consent, because it does not record what the person was asked.

So: if you send marketing through this service, the evidence of consent must be yours. Keep it in your own records. Do not rely on these flags as proof that a recipient consented, because they are not proof and we will not represent them as such.

3.4.1 Operational messages and campaign messages are different things in law

Keep the two apart in your own head, because the law does, and because the software does not.

• Operational — "Your engineer will arrive between 2 and 4pm", "Your appointment is confirmed", "Job #4412 completed — invoice attached". A message whose sole purpose is to complete or confirm a transaction the recipient has already agreed to, to deliver a service they are entitled to, or to give warranty, recall, safety or security information. This is what the service is built for.
• Campaign — "Book your annual service now — 15% off", a seasonal promotion, a product announcement, a reactivation push to old customers. This is direct marketing wherever it lands, and it needs a lawful basis of your own before it leaves the building.

⚠ The customer's preference cannot separate the two, as the bullets above say: one pair of contact flags governs both, and there is no campaign object or send list in the product at all. The software does record a purpose against each message when it decides whether to send it — transactional, automated, marketing or account-security — but that is our classification of our own sends, applied at the moment of sending; it is not a per-message audit record you can produce later, and it is not something your customer can choose between. So you must maintain the separation, and neither of us can produce a product record that proves a given message was operational rather than promotional. Where that evidence matters to you, keep it yourself.

3.4.2 Where campaign messages need more than a European legitimate interest

A business-to-business "legitimate interests" assumption imported from European practice is wrong in at least three of the places our customers send messages, and we would rather tell you than let you find out:

3.4.3 ⭐ Singapore text messages — we may be a sender too, so we set a rule

Singapore's Do Not Call rules define a "sender" as anyone who sends a message, causes it to be sent, or authorises its sending — and the regulator has said plainly that a person is caught even where the message was sent on behalf of, or for the purposes of, someone else, with both the brand and the sending platform treated as senders. ⚠ Being a data intermediary is expressly no defence. So a campaign SMS you send through the service to a Singapore number can make us a sender as well as you.

Accordingly, you must not send a campaign SMS to a Singapore telephone number through the service unless you can evidence, on request, either (a) a check of the relevant Do Not Call register within the prescribed period before sending, or (b) clear and unambiguous consent from the subscriber, recorded in written or other accessible form. Every such message must also identify who sent or authorised it, with contact details that will remain valid for at least thirty days, and must not conceal the sending line. Operational messages as described in 3.4.1 are outside these rules.

⚠ If we cannot satisfy ourselves that this is being observed, we may suspend SMS sending to Singapore telephone numbers from your account entirely — we cannot block only the campaign traffic. Since 6 September 2026 each send does carry a purpose, but that purpose is derived from which feature sent it, not from what it says, and there is no campaign or bulk-messaging feature in the product at all: a promotional text a person composes and sends from a customer record travels the same path as an operational one. So there is no "campaign SMS" for us to block. That is a decision about our own exposure as a possible sender, not a judgement about your business, and we would tell you before doing it.

3.4.4 ⚠ Four regimes we have not researched, and what that means

Canada's anti-spam law (CASL), the United States Telephone Consumer Protection Act, the United Kingdom and European direct-marketing rules under the e-privacy regime, and Australia's Spam Act 2003 and Do Not Call Register Act 2006 were not researched in the work behind this policy. Australia's own privacy principles expressly give way to the last two where they apply.

Two consequences, and they run in both directions:

1. We make no marketing-compliance claim for Canada, the United States, the United Kingdom, the European Union or Australia, and nothing in this policy or anywhere else in our documents should be read as one.
2. You must not assume the Singapore analysis in 3.4.3 transfers. Those regimes have their own rules about who counts as a sender, who is responsible for an agent's sending, and what consent looks like, and we have not established what they are.

If you send campaign messages into any of those countries, take your own advice. Section 2 of this policy already puts the lawfulness of what you send on you; this is us being specific about where our own knowledge runs out.

3.5 Security

You must not:

• attempt to gain access to any account, workspace, database or system that is not yours — including any other tenant's data;
• probe, scan or test the security of the service, or run penetration tests, load tests, vulnerability scanners or automated attack tooling against it, without our prior written consent;
• circumvent or attempt to circumvent authentication, permissions, module gating, rate limits, the field-engineer scope restrictions, or any other control;
• interfere with the service's operation, or with any other customer's use of it;
• reverse engineer, decompile or disassemble the software, except to the extent that restriction is void under applicable law.

If you find a security flaw, tell us — do not exploit it and do not publish it. Report it to hello@field2service.com with enough detail to reproduce it. This address is also published in our security.txt at https://www.field2service.com/.well-known/security.txt, and this section is the disclosure policy it points to.

• In scope: the Field 2 Service application, the customer portal, the public booking page, the REST API and the Field 2 Service website.
• Out of scope: anything hosted by our providers rather than by us, denial-of-service and volumetric testing, social engineering of our staff or our customers, physical attacks, and automated scanning that degrades the service for other customers.
• Safe harbour. We will not pursue you, and we will not ask a provider to pursue you, for a good-faith report made against your own workspace, made without accessing, altering or exfiltrating anyone else's data, that stops at the point the flaw is demonstrated, and that is disclosed to us first and kept confidential until we have had a reasonable opportunity to fix it.
• What we will do. Acknowledge your report, tell you what we find, and tell you when it is fixed. We operate no bug-bounty programme and offer no payment.

3.6 Data extraction and automated access

• Do not scrape, crawl or bulk-extract data from the service by any means other than the features and the documented API provided for it.
• Do not use the API or webhooks to build a substantially similar competing product, or to resell access to the service.
• Do not exceed, evade or work around published rate limits, and do not run automated clients that degrade the service for others.
• Webhooks send complete records — including the full customer record on customer events — to whatever URL you configure. That is an onward transfer of personal data that you have directed. You must send it only to an endpoint you control or have properly contracted with, over HTTPS, and you are responsible for what happens to the data once it leaves us.

3.7 AI features

The AI assistant proposes; a person confirms. Almost nothing it does is applied without an explicit confirmation, and what is applied is logged and reversible. Within that:

• Do not use AI output to make a decision that has legal or similarly significant effects on a person — refusing service, pricing someone differently on the basis of who they are, an employment or disciplinary outcome, or anything similar — without a genuine human review of the decision itself.
• Smart Dispatch Auto-pilot is your decision. It is off by default. When you switch it on, a small number of scheduling actions — reassigning and re-sequencing your own engineers' working days, capped per turn, logged and reversible — are applied without a confirmation step. That is automated processing about your employees, and enabling it is your call as their employer, not ours. Consider whether it engages your own obligations before you turn it on.
• Do not present AI output to a customer as verified fact without checking it. It is assistive, and it can be wrong.
• Do not attempt to use the assistant to reach data outside your own workspace, to escalate a user's permissions, or to bypass a control that applies to that user.
• Remember that your data is sent to our AI sub-processor to answer your requests — customer names, contact details, addresses, job notes and any photo you attach. If that is not acceptable for a particular record, do not put that record through the assistant. The AI features can be switched off entirely for your company in Settings.

3.8 Account and access hygiene

You must:

• keep credentials confidential, and not share a login between people — give each person their own account;
• remove a user's access promptly when they leave or change role;
• enable two-factor authentication for accounts with administrative or financial permissions;
• scope API tokens to the minimum permissions needed, set an expiry on them, and revoke them when no longer used;
• treat public payment and quote links as confidential. Since 6 September 2026 these links expire — 90 days from issue by default, and you can change that, including to "never" — and can be revoked one at a time, or all of one customer's at once. Send them only to the customer they belong to, and revoke one that has gone astray: re-issuing restores the same address, so re-issue refreshes an expiry or undoes a revoke and is not a way to contain a leak. Links you sent before 6 September 2026 keep working until the legacy cut-off set on your account (5 December 2026 by default).

• tell us promptly at hello@field2service.com if you believe an account, token or workspace has been compromised.

3.9 Content you are responsible for

You are responsible for everything stored in your workspace: customer records, job notes, photographs, signed completion sheets, uploaded documents and messages. You must have the right to store and process all of it, and you must not store anything you would not be able to justify to a regulator or to the person it is about.

---

4. What we monitor — and what we do not

We would rather state this accurately than let you assume something untrue.

• We do not read your data or monitor your content. There is no automated content scanning, no keyword monitoring and no human review of your records in the ordinary course.
• We do log activity. Changes made in your workspace are recorded with the user, what changed, and the IP address it came from. Administrative actions we take on the platform are logged separately. Those logs exist so that you and we can reconstruct what happened.
• We record security signals; we do not operate security monitoring. Since 6 September 2026 failed sign-ins, account lockouts, password changes, two-factor removals, API-key creation and revocation, data exports, bulk permanent deletions and content-security-policy violations are written to a durable record, and four alert rules fire on it: repeated failed sign-ins from one address, one address attacking several accounts, an export outside working hours, and a batch of twenty-five or more permanent deletions. That is not intrusion detection and it is not automated abuse detection. We do not scan your content, we do not ship logs to a separate system, we do not protect the logs against alteration, nothing alerts on our administrative audit log, and there is no impossible-travel or privilege-change rule; a sign-in attempt against an address that exists in no account is not recorded at all. In practice we still learn about a breach of this policy because someone reports it, because a recipient or a provider complains, or because it shows up in ordinary support work.

• Our payment, SMS, email and AI providers operate their own acceptable-use rules, and can refuse or suspend service independently of us. Breaching their rules can interrupt yours.

---

5. Enforcement

If we believe this policy has been breached, we may take any of the following steps, choosing the least disruptive one that resolves the problem:

1. Contact you and ask you to fix it, with a reasonable deadline.
2. Disable a specific feature or user — for example SMS sending, the API, webhooks, or the AI assistant.
3. Suspend your workspace. Suspension blocks access; it does not delete anything. Your data stays where it is.
4. Terminate the subscription for a material or repeated breach, under the Terms of Service.

We will normally give notice first. We may act immediately, and without prior notice, where the breach is serious and ongoing — unlawful content, an active security compromise, an attack on the service or on another customer, unlawful bulk messaging in progress, or where a law or a provider requires us to act at once. Where we act without notice, we will tell you as soon as we reasonably can and explain why.

We may also be required to disclose information or suspend an account to comply with a court order or a lawful request from an authority.

Appeals. If you think we have acted wrongly, write to hello@field2service.com. Say what happened and why you disagree. We will look at it again and give you a reasoned answer.

Reporting abuse. If you believe someone is using Field 2 Service in breach of this policy — including receiving unwanted messages sent through it — email hello@field2service.com with the detail you have.

---

6. Changes to this policy

We may update this policy as the product and the law change. Where a change materially restricts what you may do, we will give notice by email or in the application before it takes effect. The version and date at the top of this document always identify the current text.

---

7. Contact

hello@field2service.com

Field 2 Service is operated by Go Gadgets Ltd, Cupidstown, Kilteel, Co. Kildare, Ireland, company registration number 565656. Data protection contact: [[OWNER: privacy/DPO contact or statement that no DPO is required]].

---