Skip to main content

Access Applications

An access application (AA) is the central configuration object that defines how data sharing works between a requesting organisation and data-providing individuals. It acts as a data sharing contract definition — specifying what data is requested, how it is encrypted, who can participate, and what happens at each stage of the workflow.

For a user-facing perspective on how data sharing works, see How Data Sharing Works.

Core identity​

Each access application has a human-readable name and a machine-readable key. The key and an associated secret are set when the application is created and cannot be changed afterwards — this ensures that integrations built against a specific key remain stable.

When an application is created, the system also auto-generates a secret if requested, and sets up background processing for tasks like external authentication client creation.

Configuration​

An access application carries several configuration objects that control its behaviour:

  • Ruleset — scoring and validation rules applied to submitted data
  • Scopes — which types of data the application requests access to
  • Transitions — the state machine that governs how sharing progresses (see below)
  • Theme — UI styling for the sharing interface
  • Callback and logout URIs — where users are redirected during and after the sharing flow
  • Bot protection — optional CAPTCHA integration (e.g. Cloudflare Turnstile) to prevent automated submissions

Encryption key pairs​

Each access application has its own asymmetric encryption key pair, separate from any user's personal keys:

  • The public key is used by data providers to encrypt their data before sharing. Anyone submitting data to the application can access this key.
  • The private key is encrypted with the application owner's personal public key and stored on the server. Only someone who holds both the application's private key and the personal private key to unlock it can read submissions.

This architecture ensures that data encrypted for a specific application can only be decrypted by authorised parties. For a detailed explanation of the encryption chain, see Encryption.

Authorised users (guest list)​

An access application can optionally restrict participation to an explicit list of users. When the guest list is enabled, only users on the list can share data through the application. This is useful for controlled data collection — such as onboarding a known set of clients — rather than open public submissions.

State transitions​

The transitions configuration defines the state machine that governs how a sharing instance progresses through its lifecycle. Each transition specifies:

  • The triggering event — what causes the transition
  • Start and end states — the state before and after the transition
  • Notification templates — what messages are sent when the transition occurs
  • Destinations — where notifications are delivered

Transitions enable complex workflows. For example, an application might define transitions for "submission received", "review complete", "additional information requested", and "application approved", each triggering appropriate notifications to the relevant parties.

Access applications support two mechanisms for initiating data sharing:

  • Short links — shareable URLs that provide entry points into the sharing workflow. A data provider clicking a short link is taken directly to the application's sharing interface.
  • Requests (invitations) — outgoing invitations sent to specific data providers by email or phone. Each request has its own short code and can be scheduled for deferred delivery.

Permission model​

Access applications use a layered permission model:

  • Owner — the user who created the application has implicit full access
  • Editors and admins — additional users can be granted editing or administrative access, either directly or through a permission group
  • Viewers — all users within a tenant can see application definitions, because data providers need to see the application they are sharing with. However, only authorised users can modify the application or view submitted data.