# Access and audit (/docs/en/trust/access-and-audit)



Access in Salisan is decided on the server for every request. Hiding a button in the app is a display choice and never the control.

## Roles and patient access [#roles]

Every member has a role. The built-in roles are Owner, Admin, Member and Secretary. On the Enterprise plan a practice can also create custom roles.

* **Member** reads and writes clinical records only for patients assigned to them. Calendar access covers their team.
* **Secretary** works with patients, calendars, communication and tasks across the practice, and has no clinical-record permission.
* **Admin** and **Owner** have organization-wide clinical access, plus member and team management. Only the Owner manages billing, the two-factor policy and single sign-on enforcement.

Patient access has two layers. The patient must belong to the signed-in person's practice, and the person's role must allow the action for that patient. The Agent acts with the permissions of the person using it. Export and erasure jobs check the requester's authority again when they run.

Steps for managing roles are in [People and access](/docs/en/guides/people-and-access). The concepts are in [Roles and access](/docs/en/get-started/roles-and-access).

## Separation between practices [#isolation]

Salisan's authorization rules require every query for practice data to be scoped to the signed-in person's organization. Patient records are reached only through the practice's access link to the patient. Automated tests check that every API route declares its access level.

## Salisan staff access [#staff]

Salisan staff cannot sign in as a customer. Impersonation is disabled, and platform roles do not grant access to a practice's patient data through the workspace.

The Terms of Service say Salisan treats patient data as subject to the practice's professional secrecy and discloses it only on the practice's documented instructions or where EU or Member State law requires it. Support asks you not to send patient details.

Salisan has not published a description of which staff can reach production systems or under what approval. To ask, follow [Ask Salisan](/docs/en/trust/legal-documents#ask).

## The audit log [#audit-log]

Owners and admins can open **Organization → Compliance → Audit**. A custom role needs the **View audit history** permission. The page title is **Audit log**.

The log records who signed in, who opened which record, and what was permitted or refused. It also records changes to records and to organization settings, exports, erasure requests and Agent actions.

* Each row shows the date, the actor, the action and the target. The actor type is Person, Agent, API or System.
* Open a row for the outcome, reason, source and the names of the fields that changed. The log stores field names, not their contents.
* Filter by action family (Patient access, Patient write, Organization changes, Org admin), by date range and by patient. A patient's menu also has **Access log**, which opens the log filtered to that patient.
* For an Agent action, the details name the person who started it.
* Reading the audit log is recorded as an event too.

To see what a record used to say, open the record's **History**. The audit log does not hold the earlier content.

## Retention and integrity [#retention]

Audit events are written in the same database transaction as the action they describe. A practice cannot shorten how long Salisan keeps them. The period depends on the practice's country, and Salisan has not published it.

Salisan's infrastructure configuration also archives a signed copy of each event in write-once storage (S3 Object Lock in compliance mode), encrypted with a managed key. An organization export includes these signed copies unchanged.

## Related [#related]

* [Data and compliance](/docs/en/guides/data-and-compliance)
* [Patient rights](/docs/en/trust/patient-rights)