Customers

The company sees a list of its own customers, keyed by its internal customer id (for example 90), never by a citizen DID. The view unifies, on a single row, the three forms of consent for the same person: the full consent signed by the citizen, the partial consent, and the offline consent entered by hand. One person, one id, one row.

#The customer list

The list (menu Customers) is searchable and filterable. You find each customer by your internal id, with an at-a-glance summary of their aggregate consent state. It is the entry point for opening a dossier, preparing a rights-request response, or checking what a person consented to before a data use.

#Adding customers to the register

Add a customer offers two paths: enter a customer (your id, their name, an optional email and their correspondence language) or import a list (CSV), with a template to download and a preview before the import. The name and email are encrypted at rest under your tenant key. Displays of that name or email inside Agreely are recorded in the customer's log, with their author and the screen.

#A customer dossier

Opening a customer shows their dossier, in five tabs: Overview, Consent, Requests, Integrity and Log. The Consent tab is the full view of their consent at cell granularity. It lays out every (category, purpose) cell with:

• the cell's status, accepted or declined;
• the consent document and its exact version that are authoritative for that cell;
• the assurance tier of the proof;
• the cell's offline status, and a generate claim link button that appears only when the customer holds a manual consent, to invite the person to claim and sign their proof;
• the access log scoped to this customer.

From the dossier, the company can also send a request, record a consent already obtained (paper or verbal), withdraw a consent on the person's behalf, record the end of the relationship (and revert it), place or release a destruction hold, and edit or remove the customer from the register.

#Portability export (P-39.1 s. 27, third paragraph; A-2.1 s. 84, third paragraph)

A customer's consents can be exported in JSON or CSV, and only in those two formats, by an owner or an administrator. The dossier's export menu also offers the audit dossier (ZIP), the batch verification file and the extract of this customer's log in JSON or CSV. The portability export serves the right to portability: it is structured, technology-neutral, and delivered in a commonly used format.

The export is keyed by your customer id, never by a citizen DID. It contains that person's consent as your company holds it, their name and email if they are in the register (a display recorded in the exporter's name), and nothing of the internal cryptographic representation that would let anyone correlate the person across companies.

#Company-side unlinkability

The company sees only its own customer ids, scoped to its tenant. There is no cross-company join, and no citizen DID is ever exposed on the company side. Two companies that serve the same person cannot recognize them as the same person from what each one sees. Unlinkability is structural, not a policy.

#The access log

Beyond the per-customer log, the application keeps a company-wide access log (Compliance > Access log), paged 25 entries at a time.

Its entries form a hash chain where each entry commits to the previous one, and checkpoints seal ranges of entries and are then anchored on a public chain: a change shows up as a discrepancy. The page shows the verification state: log consistent with stored fingerprints, awaiting first anchor or integrity anomaly detected. That verification compares against the hashes Agreely keeps: it is defence in depth, not independent proof. The full register export allows the comparison with the chain outside Agreely.

#Next

• Compliance: the Law 25 hub, including rights requests and erasure obligations.
• Privacy and erasure: company/citizen unlinkability and crypto-shred erasure.