Privacy tools in CustomerGate 365

What is stored

• Quote requests and their lines: name, company, e-mail, phone, addresses, VAT number, customer reference, the project (since 1.0.44), free text, an IP hash, the remark on a rejection, and the user name of whoever the request is assigned to.
• Attachments on a request: the file itself, its name, and the e-mail address of the portal user who uploaded it.
• Account requests: the same, plus the job title, the stated customer number and, for an invitation, the address of whoever invited.
• Portal users: e-mail address, name, last sign-in and the five notification flags.
• Sign-in codes and portal sessions: e-mail address and IP hash. Codes and tokens are stored only as hashes.
• Quote acceptances: the e-mail address and IP hash of the person who accepted, with their purchase order number and requested delivery date.
• Quote rejections: e-mail address, IP hash and the customer's own words in the remark.
• The portal notification queue: the recipient's e-mail address and the error text of a message that could not be sent.
• The customer switch log: e-mail address and IP hash of the person who tried to switch customer.

The IP hash is made by the website with a secret key. It is pseudonymized personal data, not anonymous data. The app registers all these fields as personal data in Business Central's data classification. The five notification flags belong there too: a checkbox looks harmless, but it is a consent, and what did I say yes to is one of the questions an access request really asks.

The screening fields (score, reasons, result and Duplicate Of) are not personal data: they hold a number, fixed English keys and a request number. Assigned To is personal data, of an employee of your own company, and the cleanup deliberately leaves it alone: that job erases data of the requester, and who handled a request is the accountability record of that handling. Neither are the inspection certificate and the processing asked for on a request line (since 1.0.44): they say something about steel, not about a person.

What a webhook sends out carries no personal data: only identifiers, states, amounts and dates, so no names, addresses, phone numbers, free text or line descriptions. The two webhook tables therefore hold none either.

Retention and cleanup

Retention Period (Days) on CustomerGate Setup sets how long personal data is kept, counted from the day a request was received. Every night at 02:00, the cleanup job then anonymizes:

• Quote requests in every status, including the text copied to the sales quote at conversion (the delivery address, the comments and, since 1.0.44, the Project line at the top; the certificate and processing lines stay) and the remark inside sales typed on a rejection. Number, status, dates, country, the rejection reason code and the quote number stay, so the link to the sales document and the count of why requests are rejected are kept. A request that is still New or In Progress becomes Rejected.
• Attachments on a request past its retention period: those are deleted, content and all. A file is not anonymized, because there is nothing left to keep. A drawing with an address on it is the data, and a row with an emptied name would only claim that there is nothing left in it.
• Account requests in every status.
• Quote acceptances: the e-mail address and the IP hash. The acceptance itself stays, because it records a commercial commitment. The purchase order number stays too: it is the customer's own reference on a commercial document, just like Your Reference on the quote.
• Quote rejections: the e-mail address, the IP hash and the remark. That last one is free text somebody typed and can contain anything; the reason is a choice from a fixed list and stays, as do the quote, the customer, the moment and the amount. Which quote was refused, when and why is business history.
• Rows of the customer switch log: the e-mail address and the IP hash. The two customer numbers, the moment and the outcome stay. Once the address is gone, that row is about two companies, and at access to another company's data that is exactly the trace that should outlive the person in it.
• Portal users that have been deactivated for longer than the retention period. An active portal user is never erased.

Expired sign-in codes are deleted a day after they expire, expired sessions after thirty days, and sent portal notifications thirty days after they went out. None of those three holds anything worth keeping: what a sent notification proves is in the recipient's mailbox a month later, not here. A notification that has not been sent yet stays; that is not an old trace but work still to be done.

Each item is cleaned on its own, so one that fails does not stop the rest; failed steps are retried the next night and shown on CustomerGate Setup. Posted documents cannot be changed: when request text has reached one, the request records that with Cleanup Incomplete. An attachment that already travelled to a sales document as a document attachment stays there; remove it on the document itself.

Keeping the cleanup running

• The cleanup job is installed on hold. Turn it on with Turn On Both Jobs once the retention period is right.
• Awaiting Cleanup on CustomerGate Setup and the retention cues on the Role Center count requests past the retention period that still hold personal data. They should be zero.
• Cleanup Disabled stops all erasure. Use it only briefly, for a test.
• Preview Cleanup counts what the next round would process, without changing anything.
• Clean Up Personal Data Now runs a round straight away.

Export per e-mail address (GDPR articles 15 and 20)

Export Personal Data, on Web Requests, Account Requests and Portal Users, creates one JSON file with every row the app holds for the e-mail address, in ten tables: quote requests with their lines, their attachments, account requests, portal users, sign-in codes, portal sessions, quote acceptances, quote rejections, portal notifications and the customer switch log.

• The switch log is in it on purpose. It is the only place where it is written down that somebody tried to reach another company's data, and that is exactly the sort of thing a data subject may see.
• The hashes and salts of sign-in codes and the token hashes of sessions are left out.
• Attachments are named, not embedded: name, size, moment, type and a SHA-256, everything except the bytes. Ten drawings of a few megabytes each as base64 would make a JSON file nobody can open. The person gets the files themselves with Download on the attachments list of the request; the hash in the export proves that a delivered copy is the file Business Central holds.
• Since 1.0.44 the request rows carry the project and the line rows the inspection certificate; the processing per line has a section of its own.
• It uses the same lookup as the erasure, so what the erasure would touch, the export shows.

Erasure per e-mail address (GDPR article 17)

Erase Personal Data erases everything for one e-mail address: the quote requests and their text on sales quotes, the account requests, the portal users, the sign-in codes, the sessions, the quote acceptances, the quote rejections, the portal notifications still in the queue, the rows in the customer switch log and the uploaded files.

• Files go entirely, content and all, including the files this person hung on the request of a colleague. Anonymizing their own requests would never reach those, and two buyers at one company is the ordinary case.
• Portal notifications still queued are deleted. A message without a recipient is not a message, and somebody who asks to be erased should not get mail tomorrow.
• Rows of the switch log are anonymized rather than deleted, for the reason above.
• Numbers, dates, the chosen customer and who reviewed stay, and an acceptance keeps its quote and date.
• It refuses while the address still has an active portal user, so deactivate first. It runs only from the Business Central client, after a confirmation.

Portal notifications are opt-in

A portal user receives no e-mail about quotes, orders, shipments, invoices or requests unless they switched that kind on themselves, in the portal, signed in. Three things stand in the way of a message nobody asked for, and each of them is needed on its own:

1. The company's master switch, Portal Notifications Enabled on CustomerGate Setup. It is off after a fresh installation and after every update.
2. The five boxes on the portal user. They are off until the person sets them, and only they can set them: inside sales can read them and there is no action that does it for a group.
3. A re-check of both at the moment of sending, so that switching off works immediately, including for messages that were already queued.

Every message says why it was sent and where to switch it off. That link points at the portal, where the recipient signs in as usual. There is deliberately no unsubscribe link that works without signing in: such a link works for whoever holds the e-mail, and it would be the one endpoint in this app that accepts an address and acts on it.

Copies of sent e-mails

Business Central keeps every sent message in Sent Email, including request details (since 1.0.44 also the project, which the confirmation and the notification to inside sales name) and sign-in codes, and the cleanup does not reach it. Set a retention policy for Sent Email on the Retention Policies page, equal to the CustomerGate retention period (the minimum there is seven days); Business Central then cleans up the messages itself.

Telemetry

Once telemetry is enabled, the app sends Van Oosten Software technical telemetry: which feature ran and with what outcome, with counts and kinds only. It never contains e-mail addresses, names, customer numbers, document numbers or error texts. Once a day per company a heartbeat goes with it: the app version, whether this is a production environment or a sandbox, which modules are present, how many requests there are by status, how many portal users are active, how many webhook subscriptions are on, whether the job queue entries are running, and the licence status, the plan and the licence number. That licence number is a Van Oosten Software number, not the licensee's name. Counts, versions, switches and the licence, not a row from any table. The privacy statement for the app has the details.