ProcessBuilder Privacy Policy

Version: 1.1 Effective date: 2026-08-23 Last updated: 2026-08-23

This is a DRAFT and it has not been reviewed by a lawyer. It is written by

the people who built the product, from the product's own source code and its

live database schema, and it is accurate about what the software does. It is

not legal advice, and it must be reviewed by a qualified lawyer before a

paying customer is asked to accept it. The open item for that review is PB-07.

Placeholders in [SQUARE BRACKETS] are facts only the vendor can supply.

docs/legal/LEGAL-OPEN-ITEMS.md lists every one of them.

---

1. Who we are and what this policy covers

ProcessBuilder is a business process, approval and electronic signature application that runs inside your organisation's own Microsoft 365 environment. It is supplied by [LEGAL ENTITY NAME], company number [COMPANY NUMBER], registered at [REGISTERED ADDRESS] ("we", "us", "our").

This policy explains what personal data we handle when you use ProcessBuilder, why we handle it, how long we keep it, and what rights you have. It applies to the ProcessBuilder application, its installation tool, and the supporting service that runs in our Microsoft Azure subscription.

This policy does not cover the personal data your own organisation chooses to collect using ProcessBuilder. Your organisation decides that, and your organisation's own privacy notice governs it. Section 3 explains the difference precisely, because it is the most important thing in this document.

---

2. Summary in plain language

If you read nothing else, read this.

Your business data stays with you. Every form you design, every submission your people fill in, every approval, every signature, every uploaded document and the complete audit record of who did what and when are all stored in your organisation's own Microsoft 365 tenant, on lists and libraries inside your own SharePoint site. They are not copied to us, and we do not hold a database of your submissions.

What we hold is small and deliberately so. In our own systems we keep the identifiers needed to know that your organisation is a customer, which site the service is permitted to work with, and a security event log. The full list is in section 5 and there is nothing in it we have not named.

We can technically reach your site, and we say so. The service holds a narrow, per site permission in your tenant so that it can apply the access rules that protect each submission. You grant that permission during installation, you can see it in your own Microsoft 365 admin centre, and you can revoke it at any time. Revoking it stops the service from working. It does not delete your data, because your data was never ours to delete.

Artificial intelligence is used in one place only. When a person designing a form asks ProcessBuilder to draft one, the description they type, or a document they choose to upload for that purpose, is sent to our model provider. Submissions, signatures, approvals and the content your people fill in are never sent to any model. Section 7 sets this out in full.

---

3. Our role, and yours

Data protection law distinguishes between the party who decides why and how personal data is processed, and the party who processes it on that party's instructions. Under the EU and UK General Data Protection Regulation those are the "controller" and the "processor". Israeli law under the Privacy Protection Law and Amendment 13 uses "database controller" and "database holder". Californian law uses "business" and "service provider". The distinction is the same in each.

Where your organisation is the controller and we are the processor. All content created through ProcessBuilder is your organisation's. That includes form definitions, submitted answers, attachments, approval decisions, signature records and the audit chain. You decide what to collect and why. We process it only to provide the service, only on your instructions, and only to the extent described in section 5. This processing is governed by the data processing terms agreed between us and your organisation.

Where we are the controller in our own right. For a small set of information we decide the purpose ourselves: our record that your organisation holds a subscription, the licence and billing contacts for it, what we sent those contacts and what changed, how much of the service was used, our security event log, and correspondence with you. That is the information in sections 5.1 to 5.4, 5.6 and 5.9.

Where your organisation is the controller and we are not involved at all. Because your data lives in your Microsoft 365 tenant, Microsoft is your processor for it under your existing agreement with Microsoft, not ours. We do not sit between your users and your own SharePoint.

---

4. Where your data lives

The content your organisation creates with ProcessBuilder is stored in your own Microsoft 365 tenant, in the geographic region you chose when you bought Microsoft 365. We do not choose that region and we do not move it.

The supporting service we operate runs in Microsoft Azure in the West Europe region. The limited data described in section 5 is stored there.

---

5. What we hold in our own systems, and why

This section is exhaustive for personal data. Every field named here exists in our systems and nothing else about your people does.

Each subsection names the database tables it describes, in the form dbo.TableName, so that a data protection review can be checked against the system rather than taken on trust. Our database holds eighteen tables and all eighteen are named in this section. That is enforced by an automated check which fails our build if a table exists that this document does not name.

5.1 Your subscription record

dbo.ProductSubscriptions, dbo.TenantSeats, dbo.TenantProfile, dbo.RevenueEvents, dbo.Plans

For each customer organisation we store the Microsoft 365 tenant identifier, the product identifier, the subscription status, plan and expiry date, the number of seats bought and who holds them, the identifiers of the security groups the product uses, a flag recording whether setup was completed, and one administrative contact email address.

We also keep, separately, a commercial record of the relationship itself: your organisation's internet domain, the organisation's name where you have given us one, the country of registration once a payment tells us what it is, when you joined and when you left, and what was paid. That record names no individual. The domain is captured from the verified sign-in of whoever registered, so it cannot be asserted by a browser.

The personal data in this section is the one administrative email address and the sign-in names recorded against the seats. We use them to identify the administrator who owns the relationship, to know who is entitled to use the product, and to contact you about your subscription and about the security of the service. Our lawful basis is the performance of our contract with your organisation, and our legitimate interest in administering and securing the service.

5.2 Your licence and billing contacts

dbo.TenantContacts

You tell us who should receive two kinds of message: invoices, receipts and payment problems, and licence matters such as a trial ending, a renewal, an allowance running low or seats running out. In most organisations these are different people, so they are two separate lists and you may put several people on each.

For each contact we store the email address, a display name if one was given, which of the two lists they are on, where the address came from, who added it and when, and whether the account still exists in your directory.

The personal data here is the address and the name. We use them to reach the right person about your subscription, and our lawful basis is the performance of our contract with your organisation.

How the addresses get there. The licence contact is set to whoever installed the product, so that somebody is reachable from the first day, and it can be changed immediately from inside the product. The billing contact is the address given to our payment provider when a subscription is started. We do not ask for either of them a second time.

We check monthly that each contact still has an account with you. That check asks your own Microsoft 365 environment whether the address still resolves to a person. It reads nothing else about them, and its only result is a yes or no stored beside the address. If somebody has left we tell your remaining administrators, because a billing contact who has left is how a subscription falls over without anybody noticing.

5.3 What we sent you, and what changed

dbo.LicenceNotifications, dbo.LicenceNotificationRecipients, dbo.EntitlementChanges, dbo.EntitlementChangeActors

We keep a record of every licence message we send: which message it was, when it was attempted, how many people it went to, whether the provider confirmed delivery, and a technical failure code where it did not. The addresses it went to are stored separately, and are deleted on the twelve month clock in section 10 while the record of the message itself is kept.

We also keep a record of every change to your entitlement: seats, plan, subscription status and contacts, from what to what, when, and what caused it. Where a person made the change rather than an automatic process, their sign-in name, their IP address and their browser are stored in a separate record which is deleted on the same twelve month clock. The change itself is not, because "seats went from 15 to 20 in August" is a commercial fact about an organisation and names nobody.

This exists so that a question about a bill has an answer with a timestamp rather than two opinions.

5.4 How much of the service you have used

dbo.UsageCounters

For each customer we count three things per calendar month: notification emails sent, drafts produced by the design assistant, and submissions received from outside your organisation. These are counts and nothing else. There is no record here of who sent a message, who wrote a draft, or who submitted anything, and there must not be: the counts exist to show you your remaining allowance on the licence screen and to bill correctly, and neither purpose needs a person's name.

5.5 The site registry

dbo.TenantSiteBindings

For each customer we store the tenant identifier and the identifier of the SharePoint site the service is permitted to work with. This is how the service knows which site is yours and refuses every other. It contains no personal data.

We deliberately built this record so that it can be added to and never edited or deleted from within the running service. Removing a customer's entry is an administrative act, not something a web request can cause.

5.6 The security event log

dbo.SecurityEvents

We record security relevant events so that we can detect and investigate misuse, and so that you can be told if something happens that affects you. Each entry holds the time, the tenant identifier, the acting user's directory object identifier and user principal name, the user principal name being acted on behalf of where an administrator is acting for another person, whether the event was recorded by our server or reported by the browser, a category such as authentication or authorisation, a severity, the endpoint involved, the type and identifier of what was acted on, the form identifier, the caller's IP address, the browser user agent string, and a structured technical note.

That technical note never contains the content of a submission. This is enforced in the software, not left to convention.

Our lawful basis is our legitimate interest, and your organisation's, in keeping the service secure and in being able to establish what happened after an incident.

5.7 The reminder queue

dbo.ReminderQueue

When a process is configured to chase an outstanding approval, we store what is needed to send the reminder at the right time: the tenant, site, form and submission identifiers, which step and which authored rule applies, the channel, when it is due, how often it repeats, how many times it may be sent, and the delivery outcome.

We do not store the recipient's email address or telephone number. The recipient is resolved from your own SharePoint at the moment of sending and is not written to our database.

5.8 External participant grants

dbo.ExternalGrants, dbo.ExternalGrantEvents

Where a process invites somebody outside your organisation to review or sign, we issue a time limited, single use grant. We store the grant identifier, the tenant and organisation domain, the form, submission and step identifiers, when it was issued and when it expires, how many actions it permits and how many have been used, and its status.

We do not store that person's email address. We store a keyed cryptographic verifier derived from it, which lets us confirm that the person following the link is the person invited, and which cannot be reversed to recover the address. Where we record the IP address of an external action we store it the same way, as a keyed hash that lets us correlate repeated activity without identifying the person. We do store the browser user agent string of an external action, unhashed, because it is what tells us that a link is being replayed by an automated tool.

5.9 Who may administer your subscription

dbo.TenantAdmins

Managing your seats, your plan, your payment details and your connections to other systems is restricted to the people your organisation names. We store, for each of them, their directory object identifier and their sign-in name, who appointed them and when, and whether they are the primary administrator who cannot be removed while they are the only one.

The person who starts the trial becomes the first administrator automatically, so that nobody is ever locked out of their own subscription on the first day.

The personal data here is the sign-in name and the object identifier. Our lawful basis is the performance of our contract with your organisation.

5.10 Your acceptance of these documents

dbo.LegalAcceptances

When somebody accepts these terms or this policy on your organisation's behalf, we record it: your tenant identifier, which document, its version, a SHA-256 hash of the exact text that was displayed, the language it was displayed in, the accepting person's directory object identifier and sign-in name, and the time in UTC.

The hash is the point. A version number records which document we believe was shown. A hash of the text records which document was actually shown, and every version of every document stays in our source repository permanently, so any hash can be resolved back to the words. That is what makes the record worth having if there is ever a disagreement about what was agreed.

Nothing ever updates or deletes a row. The table is append-only, and that is enforced by the database permissions rather than by our code: the service holds SELECT and INSERT on it and holds neither UPDATE nor DELETE. The history of what your organisation accepted is therefore the table itself.

The personal data here is the sign-in name and the object identifier. Our lawful basis is our legitimate interest, and yours, in both sides being able to establish what was agreed and when. This record is kept for as long as your organisation is a customer and for seven years afterwards, because it is evidence of a contract rather than operational data.

5.11 Support correspondence

If you contact us we keep the correspondence and whatever you choose to tell us in it, so that we can answer and so that we have a record of what was agreed. Our lawful basis is our legitimate interest in supporting our customers.

---

6. Personal data that passes through us without being stored

Some features require personal data to travel through our service on its way somewhere else. In each case it is used for that delivery and is not retained by us afterwards.

Notification email. Messages generated by your processes are sent through Microsoft Azure Communication Services in our subscription. The recipient address, subject and body pass through that service in order to be delivered.

SMS and WhatsApp notifications. Where your organisation enables these channels, the recipient's telephone number and the message body pass through the relevant messaging provider in order to be delivered.

Signature documents. When a document is signed, the finished PDF is produced by our service and written back to your own SharePoint. It is not retained by us.

Outbound integrations. Where your organisation configures ProcessBuilder to send submitted data to one of your own systems, that data is sent to the endpoint your administrator specified, using credentials your administrator supplied. We do not choose the destination and we do not keep a copy. The destination is fixed by your administrator at the time the connection is created and cannot be changed by an ordinary user's request.

Form design assistance. See section 7.

---

7. Artificial intelligence, in full

ProcessBuilder can draft a form for you. This is the only feature that uses a large language model, and it is worth being exact about what it does and does not see.

It is optional and it is only ever used deliberately. Nothing is sent to a model unless a person designing a process asks for a draft. If nobody uses the feature, nothing leaves your environment for this purpose at any point.

What is sent. The description the designer typed, or the text extracted from a document they chose to upload for that purpose, together with a technical description of the field types available. The same applies when they ask for an existing draft to be modified.

What is never sent. No submission, no answer filled in by an end user, no approval decision, no signature, no audit record and no file attached to a submission is ever sent to a model. The feature operates on the design of a form, not on anything anyone has filled in.

The exposure this creates, stated plainly. Anything a designer types into that box, and anything contained in a document they upload to it, leaves your environment and is processed by our model provider. If the uploaded document happens to hold real personal data, for example a completed paper form used as an example, that personal data goes with it. Upload blank templates rather than completed ones. The application cannot detect this for you, and the person using the feature is told so at the point of use.

Who processes it. Our model providers are named on our sub-processor page at [SUB-PROCESSOR PAGE URL], kept there rather than here so that it is always current. Our agreements with them require that inputs and outputs are not used to train models and are retained only for a short period for abuse prevention.

Prompt safety. Content submitted for form generation is treated by the system as material to be modelled and not as instructions to be followed. This is a security control and it does not change what data is sent.

---

8. Sub-processors

We use a small number of organisations to provide parts of the service. Each is bound by a written agreement covering confidentiality and data protection.

The current list, naming each organisation, what it does and where it processes, is published at [SUB-PROCESSOR PAGE URL]. It is kept there rather than in this document so that it is always current, and it is part of this policy.

At the date of this version, sub-processors are used for four purposes: hosting the supporting service and its database, delivering notification email, delivering SMS and messaging notifications where your organisation enables them, and drafting form designs on request as described in section 7. The form design function is routed through an intermediary service that forwards the request to the model provider, and both are named on the sub-processor page.

Your own Microsoft 365 tenant is not a sub-processor. It is your environment, under your existing agreement with Microsoft.

We will give notice at [SUB-PROCESSOR NOTICE CHANNEL] before adding or replacing a sub-processor, so that your organisation has an opportunity to object.

---

9. International transfers

Your business content does not leave your own Microsoft 365 tenant and therefore does not cross a border because of us.

The limited data described in section 5 is held in the European Economic Area. Where a sub-processor processes personal data outside the European Economic Area, the United Kingdom or Israel, that transfer is made under an approved transfer mechanism, which for our current sub-processors means the European Commission's Standard Contractual Clauses together with supplementary measures where required. Anthropic processes form design requests in the United States on this basis.

---

10. How long we keep things

We hold very little, and the rule is simple: personal data goes when the relationship goes, and what stays afterwards is not about people.

While your organisation is a customer, we keep the records in section 5 for as long as they are needed to run the service.

When your organisation stops being a customer, meaning the subscription ends and is not renewed, we delete the personal data we hold about your people within twelve months of that date. That covers the administrative contact address, the security event log entries, any remaining reminder queue rows, and external participant grants. The twelve month window exists so that a customer who comes back within the year does not have to be set up from nothing, and so that a dispute or an incident arising from the final period can still be investigated.

What we keep permanently, and why it is not about your people. We keep a commercial record of the relationship: your organisation's name, the Microsoft 365 tenant identifier, the country of registration, when you joined and when you left, the history of subscription status including trial periods, the plan held and every change to it, the number of seats over time, the commercial activity between us, whether the account was ever suspended and on what ground, and aggregate counts of use such as how many processes were created and how many submissions were made.

We keep this indefinitely for four reasons: so that a single organisation cannot take repeated free trials, so that a suspension cannot be undone by re-registering, so that we can meet our own accounting and tax obligations, and so that we can analyse how the product is bought and used and improve it.

This permanent record contains no personal data about any individual. An organisation's name and a tenant identifier identify a company, not a person. Aggregate counts describe volume, never content. The administrative contact address, and every other field that names a human, is deleted at the twelve month mark and is not carried into it.

Security and abuse investigations. Where an entry in the security event log forms part of an active investigation into a security incident, unauthorised access or abuse of the service, we retain that entry for as long as the investigation and any resulting legal process requires, and no longer. This is an exception to the twelve month rule, not a general reservation, and it applies only to the specific entries concerned.

Your acceptance record is an exception, and it is stated rather than buried. The rows in dbo.LegalAcceptances are kept for seven years after the relationship ends. They contain the sign-in name of the person who accepted, which is personal data, and they are kept because they are the evidence of a contract. A contract record that is deleted before the limitation period on it has run is a record that was not worth keeping.

Content in your own Microsoft 365 environment stays for as long as you keep it. We do not delete it and we cannot.

---

11. How we protect it

Access to the service is authenticated against your own Microsoft 365 directory. We do not issue passwords and we never see one.

Secrets and certificates are held in Azure Key Vault and are not present in the application delivered to your browser.

The service holds a narrow permission scoped to the single SharePoint site your administrator registered. It cannot reach any other site in your tenant, and this is enforced by Microsoft rather than by our own code.

Access rules on each submission are applied by the service rather than by the browser, so that they cannot be bypassed by a user acting directly against SharePoint.

The audit record of approvals and signatures is chained cryptographically so that a later alteration of an earlier entry can be detected.

We test these controls by measurement rather than by assertion. We periodically attempt every operation against every list the product creates, as each category of user, directly against the storage layer and bypassing our own application, and we publish the results to customers who ask. In the most recent such measurement, a user holding no permission was refused every one of the one hundred and thirty five operations attempted.

We have documented separately, in a paper available on request, what an administrator of your own SharePoint environment can technically do, because no application can prevent the owner of the storage from reaching what is stored in it. We would rather you learned that from us than discovered it.

---

12. Your rights

Depending on where you are, you may have the right to be told what personal data is held about you, to receive a copy of it, to have it corrected, to have it deleted, to restrict or object to its use, to withdraw consent where we relied on consent, and to complain to a regulator.

If your personal data is inside ProcessBuilder content, for example because you filled in a form or approved something, your request should go to the organisation that operates that ProcessBuilder installation. They hold the data and they decide what happens to it. If you send such a request to us we will pass it to them promptly and tell you that we have.

If your request concerns the information we hold as controller, meaning your subscription record, our security log or your correspondence with us, contact us at [PRIVACY CONTACT EMAIL] and we will respond within one month.

If you are in the European Economic Area or the United Kingdom, you may complain to your national supervisory authority.

If you are in Israel, you may complain to the Privacy Protection Authority.

If you are a California resident, you have the rights to know, delete, correct and opt out under the California Consumer Privacy Act as amended. We do not sell personal information and we do not share it for cross context behavioural advertising. We will not discriminate against you for exercising any of these rights.

---

13. Children

ProcessBuilder is a workplace application sold to organisations. It is not directed at children and we do not knowingly collect personal data from anyone under sixteen.

---

14. Changes, contact and references

We will post any change to this policy at [POLICY URL] and update the version and date at the top. Where a change materially affects how we handle personal data we will notify the administrative contact for each customer organisation before it takes effect.

Contact [LEGAL ENTITY NAME] [REGISTERED ADDRESS] Privacy enquiries: [PRIVACY CONTACT EMAIL] Data protection officer or privacy contact: [DPO NAME AND CONTACT, OR STATE THAT NONE IS APPOINTED] Representative in the European Union under Article 27 GDPR: [EU REPRESENTATIVE, IF REQUIRED]

Which laws this policy is written against, and what has not been checked by a lawyer

Two regimes are what an Israeli enterprise customer asks about, and both are named here so that a reviewer can see what was and was not considered.

Israel, the Protection of Privacy Law and Amendment 13. Amendment 13 came into force on 14 August 2025 and is the largest change to Israeli privacy law in decades, bringing it substantially closer to the GDPR. Three of its consequences are reflected in this document. Consent must be explicit, documented and specific, and blanket consent is no longer acceptable, which is why acceptance of these documents is recorded per document, per version and per person rather than as a single flag. The Privacy Protection Authority now has express power to impose administrative fines. And a controller must assess a processor before engaging one and must have a written data processing agreement with it, which is what section 3 and the data processing terms are for.

Appointing a privacy protection officer is NOT settled and a lawyer must decide it. Amendment 13 makes the appointment mandatory for public bodies and for controllers whose principal business is collecting personal data in order to transfer it to others, above 10,000 people. On the face of it neither describes this product, whose customers' data stays in their own environment. That reading has not been confirmed by a lawyer and it should be, because the grace period for appointments ended on 31 October 2025 and it is not a question to answer from a website.

The EU and UK General Data Protection Regulation. Where a customer is established in the EU or the UK, or offers services to people there, the GDPR applies to their use of the product and this document is written to be usable as a processor's privacy notice alongside a data processing agreement. Whether we need a representative in the Union under Article 27 depends on whether we are established there and on whom we offer services to. That is left as a placeholder above rather than answered here, and it is a lawyer's question.

Nothing in this section is legal advice. It records what the people who wrote the document read, and where they stopped.

Israel, Amendment 13 in force and its scope: https://iapp.org/news/a/israel-marks-a-new-era-in-privacy-law-amendment-13-ushers-in-sweeping-reform Israel, the officer appointment duty and the end of the grace period: https://inplp.com/latest-news/article/new-amendment-to-israeli-privacy-protection-law-and-mandatory-dpo-appointment/ Israel, the Privacy Protection Authority's power to fine: https://globallawexperts.com/israels-privacy-reforms-bite-2026-expanded/

References Anthropic, retention of commercial API data: https://privacy.anthropic.com/en/articles/7996866-how-long-do-you-store-personal-data Anthropic, use of commercial data for model training: https://privacy.anthropic.com/en/articles/7996868-i-want-to-opt-out-of-my-prompts-and-results-being-used-for-training-models

Governing language This policy is published in English and may be provided in translation. Where there is any inconsistency, the English version governs.