# States and outcomes Namirial Notify tracks each communication or signature workflow through states and events, and typically assigns a final outcome when the process closes. Understanding the difference between **states**, **outcomes**, and **events** helps you interpret transaction history, recipient actions, and affidavits correctly. This page provides representative lifecycle terminology used across Namirial Notify services. Exact labels and transitions can vary by service, interface, API, and configuration. For affidavit-generation rules and affidavit kinds, see [Evidence and affidavits](/products/namirialnotify/user-guides/evidences-affidavits). ## What is the difference? - A **state** shows the current phase of the process. - An **event** records something that happened during the process. - An **outcome** shows the final result once the process is complete. - An **affidavit kind** names the type of affidavit that certifies a specific event or summary and does not always match the state or outcome label. In practice: - states tell you **where the transaction is** - events tell you **what happened** - outcomes tell you **how it ended** ## State, outcome, and timestamp fields When you query a transaction, three kinds of fields tell you what has happened. Understanding how each behaves over time is essential if you reconcile status by polling instead of callbacks. ### State changes while the transaction is live; outcome becomes final at closure - **`State`** is updated as the transaction progresses. `Failed` records a recoverable processing or delivery failure; the platform may retry or advance to a later state. `Closed` is the final stage of the state machine and does not change afterwards. - **`Outcome`** generally remains `None` while the transaction is active. When the state becomes `Closed`, the platform derives the final outcome from the milestones recorded during the transaction. The outcome is then fixed. `Outcome: Failed` is the final result when a failure was recorded and takes priority over successful milestones. Do not treat `State: Failed` as a permanent failure or resubmit immediately. Wait for `Closed` and inspect the final `Outcome`; permanent failure is represented by `Outcome: Failed`. ### Outcome priority when events conflict Events can arrive close together or out of order. When the transaction closes and more than one outcome-like milestone has been recorded, Namirial Notify derives the final outcome by priority instead of only using arrival order. For EviNotice, the effective priority is: `Failed`, `Rejected`, `Accepted`, `Refused`, `Read`, `Received`, `Delivered`, `Sent`, `Certified`, then `None`. For EviMail, the effective priority is: `Failed`, `Rejected`, `Accepted`, `Read`, `Delivered`, `Sent`, `Certified`, then `None`. For EviSMS, the effective priority is: `Failed`, `Read`, `Delivered`, `Sent`, `Certified`, then `None`. This means a recorded higher-priority milestone can prevent a lower-priority milestone from becoming the final outcome, regardless of event arrival order. For example, a rejected notice remains rejected even if another technical event is recorded around the same time. ### Timestamp fields tell you which states were reached Each lifecycle milestone has a corresponding timestamp field (for example `NewOn`, `ReadyOn`, `SentOn`, `DeliveredOn`, `ReadOn`). A timestamp is set **only if and when** the platform records that milestone. If a milestone was not recorded, its timestamp is **null or absent**. This makes timestamps the most reliable way to determine which milestones were recorded — even after a transaction has closed. To check whether a message was delivered, for example, check whether `DeliveredOn` has a value rather than relying on the current `State` or `Outcome`. The fields available depend on the service: | Timestamp field | Meaning | EviNotice | EviMail | EviSMS | | --- | --- | --- | --- | --- | | `NewOn` / `SubmittedOn` | The submission was admitted and certification began. EviMail and EviSMS use `NewOn`; EviNotice uses `SubmittedOn`. | ✅ | ✅ | ✅ | | `ReadyOn` / `ProcessedOn` | Initial processing and content certification finished; the communication is ready to send. EviMail and EviSMS use `ReadyOn`; EviNotice uses `ProcessedOn`. | ✅ | ✅ | ✅ | | `DispatchedOn` | The communication was handed to the sending process or delivery channel. It has not yet been accepted by the remote system. | ✅ | ✅ | ✅ | | `SentOn` | Transmission was accepted by the remote system. For EviNotice, this applies to the notification sent by email, SMS, RCS, or WhatsApp, not to the hosted content. For EviMail, the recipient's mail server accepted the email; for EviSMS, the operator accepted the SMS or RCS message for routing. | ✅ | ✅ | ✅ | | `DeliveredOn` | Delivery to the recipient was confirmed (see the service-specific [caveats](#why-delivery-and-read-tracking-can-be-incomplete) below). | ✅ | ✅ | ✅ | | `ReceivedOn` | The recipient followed the notification link and reached the hosted notice flow before opening the content. EviNotice only. | ✅ | — | — | | `ReadOn` | The recipient opened or read the content (see the service-specific [caveats](#why-delivery-and-read-tracking-can-be-incomplete) below). For EviSMS, set only for rich-channel (RCS) deliveries; plain SMS has no read receipt. | ✅ | ✅ | ✅ | | `RefusedOn` | The recipient explicitly refused the notice before reading it, when that feature is enabled. | ✅ | — | — | | `AcceptedOn` / `RejectedOn` | The recipient explicitly accepted or rejected the communication, when commitment is enabled. | ✅ | ✅ | — | | `ExpiredOn` | The lifecycle closed and tracking ended. This commonly occurs when the time-to-live elapses, but some flows close earlier after a recipient action or another finalizing event. | ✅ | ✅ | ✅ | **Acceptance — which field to use** The term "acceptance" can refer to different milestones: - **Processing and certification by Namirial Notify**: use `ReadyOn`, or `ProcessedOn` for EviNotice. - **Handoff to the sending process or delivery channel**: use `DispatchedOn`. - **Acceptance by the recipient's mail server or operator**: use `SentOn`. **Timestamp ordering** `DispatchedOn` is recorded when the message is handed to the sending process — at processing time — so it typically matches `ProcessedOn` (or `ReadyOn`) to the second and **precedes** `SentOn`, which is only set once transmission is confirmed. The normal logical order is: `SubmittedOn`/`NewOn` → `ProcessedOn`/`ReadyOn` → `DispatchedOn` → `SentOn` → `DeliveredOn` → `ReceivedOn` → `ReadOn`. Not every milestone is guaranteed to produce a timestamp. For example, a recipient can follow a notification link even if the recipient's mail infrastructure did not report delivery, so `ReceivedOn` or `ReadOn` can be present while `DeliveredOn` is absent. Timestamps recorded within the same second come from independent processing steps and do not provide a deterministic order. ### Why delivery and read tracking can be incomplete Delivery and read timestamps depend on the signals available for the service and channel. They can therefore be absent even when the communication reached the recipient. The meaning of each timestamp is consistent across providers for a given channel. What can vary is signal availability: some providers report a delivery or read event while others do not. A missing timestamp means that the platform did not receive the corresponding signal, not that the field has a different provider-specific meaning. **EviNotice** - `DeliveredOn` is set from best-effort delivery signals reported by the recipient's mail infrastructure. These depend on the recipient's server and client configuration, which may block them, so `DeliveredOn` can be absent even when the notification email was delivered. - `ReceivedOn` is set when the recipient clicks the notification link and reaches the hosted notice. - `ReadOn` is set after the recipient completes any required identification or validation step and is shown the actual content. In the normal hosted-notice flow, `ReceivedOn` precedes `ReadOn`, but treat them as independently recorded milestones. **EviMail** - `DeliveredOn` is set when the platform receives a Delivery Status Notification ([DSN](https://datatracker.ietf.org/doc/html/rfc3464)) from the recipient's mail server. Many mail servers do not send a DSN, so a missing `DeliveredOn` does not mean the message was not delivered. - `ReadOn` is set when the platform records a supported signal that the message was opened or read. The available signals depend on the recipient's mail client and how the content is accessed, so `ReadOn` is best-effort and may remain absent. **EviSMS** - `SentOn` is set when the telco operator accepts the message for routing, confirmed by a GSM/SMPP delivery receipt (DLR). - `DeliveredOn` is set when a DLR confirms delivery to the recipient's terminal. - `ReadOn` is set only for rich-channel (RCS) deliveries that report a read event. Plain SMS has no read receipt, so `ReadOn` stays absent for SMS-only delivery. Because delivery and read milestones rely on independent signals, you can see `ReadOn` set while `DeliveredOn` is absent. This is expected: an open or read was recorded even though no delivery notification was received. A user may also have several mail clients open at once, and which one reports first can change the signals received. ### Affidavits are generated asynchronously When a transaction reaches a state and its timestamp is set, the corresponding affidavit can take a few seconds or minutes to become available, because affidavits are generated asynchronously. A state timestamp can therefore be present before its affidavit is published. Affidavits for a transaction are expected to be available by the time it reaches `Closed`. The presence of a transmission-result affidavit does **not** by itself confirm delivery. The same affidavit kind is generated whether or not delivery succeeded — the actual result is recorded in the state timestamps and the event history, not in the affidavit kind. Use `DeliveredOn` (and the per-event details) to determine the delivery result. ## States States describe the progression of a transaction from creation to closure. ### Certified delivery services Certified delivery services, including **EviNotice**, **EviMail**, and **EviSMS**, typically use the following states: - **Draft** — the communication is saved but not yet sent. - **New** or **Submitted** — the communication was admitted for certification and is waiting to be processed. - **Ready** or **Processed** — the communication was processed and is ready to be sent. - **Dispatched** — the platform completed its checks and accepted responsibility for the communication; it is not yet sent. - **Sent** — transmission was confirmed by the remote system (for example, the recipient's mail server or the telco operator). `Dispatched` always precedes `Sent`. - **Delivered** — the communication or notification reached the recipient. - **Received** — for hosted-notice flows such as EviNotice, the recipient followed the notice link and reached the hosted notice flow before opening the content. - **Read** — the recipient opened the content, where this milestone is supported and exposed as a status. - **Replied** — for EviNotice, the recipient accepted or rejected the notice. Refusal closes the evidence with a `Refused` outcome instead of using `Replied`. - **Closed** — tracking is complete and no further status changes are expected. - **Failed** — a recoverable processing or delivery failure occurred. The platform may retry or advance to a later state. Status names can vary slightly by service, screen, or API. For example, some views show `Ready`, while others show `Processed`; some use `Sent`, while others also show `Dispatched`. The following diagrams show the normal evidence lifecycle for certified delivery services. They focus on persisted evidence states and final outcomes. Event-history screenshots are shown separately in the Events section. #### Shared notification evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> Processing : Draft → New / Submitted Processing --> Processing : New / Submitted → Ready / Processed Processing --> Delivery : Ready / Processed → Dispatched Delivery --> Delivery : Dispatched → Sent Delivery --> Closure : Tracking ends → Closed Delivery --> Closure : Failed outcome → Closed note right of Processing Exact labels vary by service. EviMail and EviSMS use New and Ready. EviNotice uses Submitted and Processed. end note ``` #### EviNotice evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> Submitted : Draft → Submitted Submitted --> Processed : Submitted → Processed Processed --> Dispatched : Processed → Dispatched Dispatched --> Sent : Dispatched → Sent Sent --> Delivered : Sent → Delivered Delivered --> Received : Delivered → Received Received --> Read : Received → Read Delivered --> Replied : Replied (state ≥ Dispatched) Received --> Replied : Replied (state ≥ Dispatched) Read --> Replied : Replied (state ≥ Dispatched) Read --> Closed : Closed (CommitmentChoice Disabled) Replied --> Closed : Accepted / Rejected outcome Dispatched --> Closed : Refused outcome Sent --> Closed : Refused outcome Delivered --> Closed : Refused outcome Received --> Closed : Refused outcome Sent --> Failed : Failed outcome Failed --> Closed : Closed after failure note right of Replied Refused is a closure path, not a Replied path. When CommitmentChoice is Disabled, Read triggers immediate closure. end note ``` #### EviMail evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> New : Draft → New New --> Ready : New → Ready Ready --> Dispatched : Ready → Dispatched Dispatched --> Sent : Dispatched → Sent Sent --> Delivered : Sent → Delivered Delivered --> Read : Delivered → Read Sent --> Replied : commitment received Delivered --> Replied : commitment received Read --> Replied : commitment received Replied --> Closed : Accepted / Rejected outcome Sent --> Closed : TimeToLive elapsed Delivered --> Closed : TimeToLive elapsed Read --> Closed : TimeToLive elapsed Sent --> Failed : Failed outcome Failed --> Closed : Closed after failure note right of Replied Commitment (accept/reject) can be registered from Sent, Delivered, or Read — not only after Read. Technical retries and recovery paths are omitted. end note ``` #### EviSMS evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> New : Draft → New New --> Ready : New → Ready Ready --> Dispatched : Ready → Dispatched Dispatched --> Sent : Dispatched → Sent Sent --> Delivered : SMS delivered Sent --> Closed : TimeToLive elapsed Delivered --> Closed : SMS delivered outcome Delivered --> Read : RCS read path Read --> Closed : RCS read outcome Sent --> Failed : Failed outcome Failed --> Closed : Closed after failure note right of Read SMS usually closes after Delivered. RCS may include Read before closure. end note ``` Event timeline examples from transaction history: - EviNotice event timeline: ![EviNotice event timeline](/assets/evinotice_timeline.99c5588c2aa2630c9a1b5546b2e2e7f3eafdf31e198678f75c427e493a253b7c.6fd6141d.png) - EviMail event timeline: ![EviMail event timeline](/assets/evimail_timeline.781f4d16fd615397abde784391c477980824842e9842f9e1ebfa0d8016ebdc96.6fd6141d.png) - EviSMS event timeline: ![EviSMS event timeline](/assets/evisms_timeline.997e0aa43a983d456a28ddcb49214bbc55a6a9435c6b42b8e40f814930bf1c69.6fd6141d.png) ### Signature workflows **EviSign** uses states such as: - **Draft** — the signature request is prepared and can still be edited. - **Submitted** — the request was admitted for processing. - **Processed** — the content was certified and the signing workflow was prepared. - **Sent** — signature requests were sent to recipients. - **Closed** — the signature process reached its end. Some source-defined EviSign states, such as `Forwarded` and `Received`, may appear in specific or legacy flows. The simplified lifecycle diagram focuses on the main source-backed progression used for documentation. The following diagrams separate the overall EviSign evidence lifecycle from the per-signer or per-party lifecycle. #### EviSign evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> Submitted : Draft → Submitted Submitted --> Processed : Submitted → Processed Processed --> Sent : Processed → Sent Sent --> Closed : Signed outcome Sent --> Closed : Rejected outcome Sent --> Closed : Cancelled / Expired / Failed outcome note right of Sent Signer actions are detailed in the party lifecycle. Forwarded and Received are source-defined but omitted from the normal main flow. end note ``` #### EviSign signer party lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> Signed : None → Signed [*] --> Rejected : None → Rejected note right of Signed Party Sent exists in source but is not shown as a confirmed persisted party status in the reviewed main flow. end note ``` EviSign event timeline: ![EviSign event timeline](/assets/evisign_timeline.4f4d01caa7e34a066abef77cad2f35edac099d652f9876bcd1e1ebcd20e46024.6fd6141d.png) ### Postal delivery **EviPost** uses states such as: - **Draft** — the postal communication is saved but not yet sent. - **Submitted** — the communication was admitted for postal processing. - **Processed** — the communication was processed and prepared for dispatch. - **Dispatched** — the request entered the postal workflow. - **Sent** — the communication was handed to the postal operator. - **Delivered** — the postal process reached the delivery stage, where this status is exposed. - **Closed** — the postal process completed and no further tracking is expected. Some interfaces may also show **Issued** as an intermediate status. EviPost uses postal result states that represent alternative outcomes before closure. They should not be read as a strict sequence. #### EviPost evidence lifecycle ```mermaid %%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%% stateDiagram-v2 [*] --> Submitted : Draft → Submitted Submitted --> Processed : Submitted → Processed Processed --> Dispatched : Processed → Dispatched Dispatched --> Issued : Dispatched → Issued Issued --> Sent : Issued → Sent Sent --> Closed : Sent as final outcome Sent --> Failed : Sent → Failed → Closed Failed --> Closed Sent --> Undelivered : Sent → Undelivered → Closed Undelivered --> Closed Sent --> Delivered : Sent → Delivered → Closed Delivered --> Closed Sent --> Disposed : Sent → Disposed → Closed Disposed --> Closed Sent --> Cancelled : Sent → Cancelled → Closed Cancelled --> Closed note right of Sent Postal result states are alternatives, not a strict sequence. Sent can also be a final outcome, closing directly. Expired is an outcome, not a persisted state. It can be set from any non-closed state — the saga bypasses the normal state guard specifically for the Expired outcome. end note ``` ## Outcomes Outcomes describe the final result of a transaction. The outcome usually starts as **None** and becomes final when the process reaches **Closed**. ### Certified delivery outcomes For services such as **EviNotice**, **EviMail**, and **EviSMS**, common outcomes can include: - **None** — the process is still open and no final result exists yet. - **Certified** — the content was certified, but the final delivery result is not yet confirmed. - **Sent** — the communication was sent, but no later recipient event was confirmed. - **Delivered** — the communication reached the recipient’s inbox, device, or access channel. - **Received** — in hosted-notice flows such as EviNotice, the recipient reached the notice flow before reading the content. - **Read** — the recipient opened the communication, where supported. - **Accepted** — the recipient explicitly accepted the communication. - **Rejected** — the recipient explicitly rejected the communication. - **Refused** — in services that support explicit refusal before opening or reading, the recipient refused the communication. - **Failed** — the process could not be completed because of an error. **Terminology note** - Outcome labels can vary by service or interface. For example, some contexts use `Rejected`, while others use `Declined` for refusal-like outcomes. - Some interfaces display the final field as `Result` instead of `Outcome`, while keeping the same interpretation. - Affidavit labels can use different names from outcomes — for example `Committed` or `Refused` — because affidavits certify specific events rather than final lifecycle status names. ![Certified delivery outcome example](/assets/certified_delivery_outcome.6a2c0ed6d33b9cf565f99ea0ad21ad46fb1e22beb8f5c6619ee22aeb16bf17ff.6fd6141d.png) ### Signature outcomes For **EviSign**, common outcomes include: - **None** — the signature process is still open. - **Signed** — all required signatures were completed. - **Rejected** — a signer rejected the document or workflow. - **Expired** — the signing time limit was exceeded. - **Cancelled** — the issuer cancelled the signature request. - **Failed** — an error prevented normal completion. **Terminology note** - In signature workflows, **Rejected** usually means an explicit refusal action on the document or process. - `Declined`, where shown by specific interfaces, can indicate a withdrawal or a refusal path that differs from a standard rejection action. - Some EviSign screens display `Result` for the final value — for example `Signed` — instead of `Outcome`. ![Signature outcome example](/assets/signature_outcome.861cb00dea0f3a95e341a78090bfda674a694e6bb47fa387c898391ca8d4c4fd.6fd6141d.png) ### Postal delivery outcomes For **EviPost**, common outcomes include: - **None** — the postal process is still active. - **Delivered** — the postal communication was successfully delivered. - **Declined** — the recipient refused acceptance of the postal communication. - **Rejected** — the recipient rejected the postal communication. - **Cancelled** — the issuer cancelled the request. - **Expired** — delivery could not be completed within the service limits. - **Failed** — an error prevented normal postal completion. **Terminology note** `Declined` and `Rejected` are the canonical EviPost outcome names for postal refusal scenarios. `Declined` applies when the recipient refuses acceptance at delivery; `Rejected` applies when the recipient rejects the postal item. Other non-delivery outcomes such as `Undelivered` or `Disposed` may also appear depending on what the postal operator reports. ## Events Events are recorded facts that occur during the process. Not every event changes the state, but events provide the detailed history used to understand what happened and, in some cases, to generate affidavits. This section uses representative event names for interpretation. Service-specific and affidavit-specific taxonomies can differ by configuration and are documented in: - [Services](/products/namirialnotify/services) - [Evidence and affidavits](/products/namirialnotify/user-guides/evidences-affidavits) ### Common delivery events For services such as **EviNotice**, **EviMail**, and **EviSMS**, representative event names can include: - **New** — the communication was admitted for certification. - **Certified** — the content was certified and prepared for sending. - **Retry** — a temporary issue occurred and the system will try again. - **Submitted** — the communication was submitted to the sending flow. - **Dispatched** — the communication has left the initial preparation phase and has been handed to the service-specific sending process. The exact meaning depends on the service. For EviMail, `Dispatched` occurs before `Sent`; it means sending has been requested and the message is ready for the sender component. - **Sent** — the recipient's server, operator, or delivery channel accepted the transmission. - **Delivered** — the communication or notification reached the recipient. - **Received** — in hosted-notice flows, the recipient reached the notice flow before opening the content. - **Read** — the recipient opened the communication, where supported. - **Accepted** — the recipient accepted the communication. - **Rejected** — the recipient rejected the communication. - **Refused** — the recipient explicitly refused the communication before opening or reading it, where that path is supported. - **Delayed** — a delivery-status notification reported a temporary delivery delay. - **Relayed** — a delivery-status notification reported that the message was relayed through another system. - **Expanded** — a delivery-status notification reported that a distribution list or alias expanded the message to additional recipients. - **Failed** — a failure event or failed attempt occurred. Some services may retry and later close with a final outcome. For EviMail, wait for `Closed` with a final `Outcome` before treating the communication as permanently failed. - **Expired** — the tracking period ended. Not every service exposes every event name in the same way. Technical DSN events such as `Delayed`, `Relayed`, and `Expanded` help explain email delivery processing and do not necessarily mean the final outcome has changed. Treat these names as interpretation anchors, then verify the exact labels shown in the transaction timeline. ![Delivery event timeline example](/assets/evinotice_timeline.99c5588c2aa2630c9a1b5546b2e2e7f3eafdf31e198678f75c427e493a253b7c.6fd6141d.png) ### Signature events For **EviSign**, representative events include: - **Submitted** — the document was admitted for processing. - **Processed** — the document was certified and the signing workflow was prepared. - **Sent** — the signature request was sent. - **FullySent** — the request was sent to all signers. - **Delivered** — a signer received the request. - **FullyDelivered** — all signers received the request. - **Signed** — a signer completed the signature. - **Rejected** — the signer rejected the document or signature request. - **Declined** — a signer withdrew from the process. - **Cancelled** — the issuer cancelled the workflow. - **Expired** — the signing time limit was exceeded. - **Closed** — the signing process completed. Depending on configuration, signer-level and workflow-level labels can both appear in history. ![EviSign event timeline example](/assets/evisign_timeline.4f4d01caa7e34a066abef77cad2f35edac099d652f9876bcd1e1ebcd20e46024.6fd6141d.png) ### Postal delivery events For **EviPost**, the event history can include steps such as: - admission of the postal communication - processing and certification of the content - printing of the document - enveloping or packaging - dispatch to the postal operator - delivery attempt or delivery failure - delivery confirmation - recipient refusal, where reported - closure of the postal process Postal event granularity depends on the selected service profile and on what the postal operator reports back. ## How to read a transaction history 1. Check the **state** to understand the current phase of the transaction. 2. Review the **events** to see what happened during the process. 3. Check the **outcome** once the process is closed to confirm the final result. 4. Use the outcome and event history together when interpreting affidavits. ## Related concepts - [The platform and the products](/products/namirialnotify/user-guides/platform-products) - [Evidence and affidavits](/products/namirialnotify/user-guides/evidences-affidavits) - [Archiving and retention](/products/namirialnotify/user-guides/archiving)