What this is, and who it is for
Trialion tells people very little, on purpose. This page is the complete inventory of what it sends: the e-mails, the two in-app notifications in the bell, and the alerts operators receive. If a process of yours depends on someone being told, check here first: if a message is not on this page, it does not exist, and your procedure has to say who tells whom.
Where to find it
E-mails arrive in the person's mailbox. The bell in the top bar of the application carries the in-app notifications. The status of a queued mail (queued, sent, delivered, failed) is shown beside the person on the Organization Team screen (a status chip) and on the Study Team screen (the Email status column). Operator alerts go to the addresses in ALERT_EMAILS.
What you can do
You cannot configure what is sent, and you cannot switch a message off: there are no notification preferences. An administrator can resend an invitation (the earlier link stops working), and an operator sets the sender, the mail server and the alert addresses (Configuration).
Every message
The e-mails the application sends
Every one of these is queued in the same database transaction as the change that causes it and sent by the worker, so a mail is never lost between the change and the send. Every e-mail comes from the platform, is not replied to, and carries the same Trialion header and footer.
| Sent when | To | Button | |
|---|---|---|---|
| {Organization} is set up on Trialion CDMS | An organization is provisioned and you are named its administrator. It lists the first steps: sign in, choose roles, invite your team, create the first study | the first Organization Admin | Sign in and start setup |
| You've been added to {organization} (no role) | Someone adds you to the organization with no organization-wide role. It says you cannot sign in yet and that you will be told when a study gives you a role | the person added | none |
| You've been added to {organization} (with a role) | Someone adds you to the organization with an organization-wide role | the person added | Sign in to Trialion |
| You've been added to {study} as {role} | You are assigned a role on a study; the site is named for a site role. A site role other than the principal investigator takes effect once the investigator has signed the delegation | the person assigned | Sign in to Trialion |
| Study {code} is created and ready to set up | A study is created. It lists the next steps | the person who created it | Open your studies |
| Your Trialion sign-in code | You ask to sign in | the address asked for | the code is the sign-in |
| Your Trialion signature code | You start an electronic signature | the signed-in person | the code is the signature step |
Why a person with no role gets no way in. Signing in needs at least one role, and the system refuses a code to a person with none. A button that led there would lead to a refusal, so the message says what is true: you were added, and you will be told when you can sign in. Being added to a study is what changes that.
An invitation's link opens the invitation page and works for 72 hours from the moment the mail is sent; an administrator can send a fresh one. The link is a credential: it is never written to a log. Codes (sign-in and signature) are sent inside the request that asks for them, never queued, because a queued code could arrive after it expired; the request therefore waits for the mail provider, and the dialogs say a code can take up to half a minute.
The platform console's e-mails
| Sent when | To | |
|---|---|---|
| Console sign-in code | A platform administrator asks to sign in | the administrator |
| Invitation to be a platform administrator | A Super-Admin invites another. It says who invited, carries a link to the console when CONSOLE_URL is set, and holds no password or code | the invited administrator |
Operator alerts
An alert is mailed to the operators' addresses (ALERT_EMAILS) when a health condition starts, as [CDMS CRITICAL] or [CDMS HIGH], and once more when it clears, as [CDMS RESOLVED]; a condition that persists is repeated at most every six hours (ALERT_COOLDOWN_MS). An alert always also goes to the log. The conditions the worker watches: the audit chains no longer verify; the audit outbox is behind; the audit ledger could not be anchored or its partitions made; the summary tables lag or disagree with the raw tables; mail is not leaving or no mail relay is running; exports are stalled; and a backup has never been taken or is stale. Alerts name the condition and carry no clinical data.
The bell (in-app)
| Notification | Raised when |
|---|---|
| Added to {study} | You are assigned a role on a study. It reads "You were assigned the {role} role on {study}", names the site for a site role, arrives once however many workspaces the role is held in, and links to the study team |
| Study {code} created | A study you created is created. Links to the study |
That is the complete list. The system has one category of notification today.
Message kinds in the code
The names the system uses for the messages above, as they appear in logs, the mail outbox and tests:
| Kind | Message |
|---|---|
organization_created | The organization is set up (first administrator) |
invitation | You've been added to an organization (with or without a role) |
role_assigned | You've been added to a study as a role |
study_created | Study created and ready to set up |
otp.sign_in | Your sign-in code (sent in the request, never queued) |
otp.signature | Your signature code (sent in the request, never queued) |
alert.health | Operator alerts: [CDMS CRITICAL], [CDMS HIGH], [CDMS RESOLVED] |
console.otp | The platform console's sign-in code |
console.admin_invitation | An invitation to be a platform administrator |
What the system records
Each mail is a row with a status: queued, sent, delivered, bounced, failed or cancelled. A failed send is retried with a doubling wait (2, 4, 8 ... seconds, at most ten minutes) up to ten attempts; a worker that dies mid-send has the mail retried when its lease ends. With plain SMTP nothing reports a delivery, so a mail stops at sent and the screens say so; a mail service that signs its delivery events (MAIL_WEBHOOK_SECRET) moves it on to delivered or bounced. Whoever asked for a resend and when is in the audit trail (platform.invitation.resent). Sending a mail is not itself a clinical event and is not in the study's audit trail.
What is deliberately not notified
There is no message for:
- a query being raised, answered, closed, reopened, or passing its response time;
- a visit becoming due, or falling out of its window;
- a serious adverse event's report clock approaching or passing;
- a record awaiting signature;
- a source-data-verification item becoming stale;
- a version awaiting your sign-off;
- an export becoming ready or expiring;
- a site being activated or suspended;
- a document being uploaded or approved.
What to use instead
Pull rather than push:
| Instead of a notification | Use |
|---|---|
| Query alerts | Query aging and the study's Queries screen |
| Visit window alerts | Visit compliance |
| Serious event clocks | The SAE Log and Lock readiness |
| Verification backlog | SDV Monitoring: pending and stale are both in the queue |
| Records awaiting signature | Casebook completion and E-Signatures |
| Versions awaiting sign-off | Study Versions |
| Deviations | Protocol deviations |
If your process depends on someone being told, build that step into your procedure.
What you cannot do, and why
- Choose what you are told. There are no preferences, so every message here is sent to everyone it applies to.
- Receive a message about work waiting. Nothing in the product pushes a reminder; see the list above.
- Rely on a delivery report with plain SMTP. Without a mail service that reports delivery, the status stops at
sent.
Compliance Q&A
No. Raising, answering and closing a query, and passing its response time, send no e-mail and no in-app notification. Sites find their work on the Queries screen. If sites must be told, your procedure has to say who tells them and how.
Codes are never queued, never written to the outbox and never logged: a code is sent inside the request that asks for it, and the outbox refuses any message whose data carries a key named code, token, link or secret. The development shortcuts that show a code on screen or in a log are refused at start-up in production and staging.
Limits: a code travels by e-mail, so it is as safe as the recipient's mailbox. Controlling access to mailboxes (and signing out of shared devices) is your responsibility.
Evidence: server/src/modules/platform/mail/domain/mail-kinds.ts (assertNoSecrets)server/src/modules/platform/auth/infrastructure/otp-email-delivery.tsserver/src/config/env.ts (OTP_DEV_CODE_IN_RESPONSE, MAIL_DEV_ECHO_LINKS refused in production and staging)
Related
Signing in · Invite and manage members · Configuration · Audit events · Platform console: sign in and administrators