Post-Published Lifecycle
Altinn 3 Correspondence post-published lifecycle and recipient interactions.
Post-Published Lifecycle
After a correspondence is published, recipients can interact with it:
flowchart TD
%% Post-published flow
A[Start: Published] --> B{Recipient Actions}
B -->|GetOverview or GetDetails| C[Set Status: Fetched]
B -->|Download Attachments from any state| G[Set Status: AttachmentsDownloaded]
C --> D{Recipient Actions}
D -->|Mark as Read| E[Set Status: Read]
D -->|Continue to Confirm| H{Confirm?}
E --> H{Confirm?}
H -->|Yes| J[Set Status: Confirmed]
H -->|No or Not Required| L{Purge?}
J --> L{Purge?}
G --> L
L -->|By Recipient| N[Set Status: PurgedByRecipient]
L -->|By Altinn| O[Set Status: PurgedByAltinn]
L -->|No| P[End]
N --> P
O --> P
style A fill:#f9f,stroke:#333,stroke-width:2px
style P fill:#f9f,stroke:#333,stroke-width:2px
style C fill:#99ff99,stroke:#333,stroke-width:2px
style E fill:#99ff99,stroke:#333,stroke-width:2px
style G fill:#99ff99,stroke:#333,stroke-width:2px
style J fill:#99ff99,stroke:#333,stroke-width:2px
style N fill:#87ceeb,stroke:#333,stroke-width:2px
style O fill:#87ceeb,stroke:#333,stroke-width:2px
Post-Published Status States
- Fetched: Recipient has accessed the correspondence (via GetOverview or GetDetails API)
- Read: Recipient has explicitly marked the correspondence as read (requires prior Fetched status)
- AttachmentsDownloaded: Recipient has downloaded one or more attachments (can occur at any time)
- Confirmed: Recipient has confirmed the correspondence (requires prior Fetched status, not Read)
- PurgedByRecipient: Correspondence has been deleted by the recipient
- PurgedByAltinn: Correspondence has been deleted by the system
Status Rules
- Fetched is automatically set when recipients call GetOverview or GetDetails
- Read requires explicit action via
/markasreadendpoint and requires prior Fetched status. This status is optional - recipients can confirm directly from Fetched without reading - Confirmed requires explicit action via
/confirmendpoint and requires prior Fetched status - AttachmentsDownloaded can occur from any published state and does not require Read status
- Confirmation is only required if the correspondence has
IsConfirmationNeeded = true
Recipient Interaction Process
Fetching Correspondence
- Recipients access correspondence details (triggers Fetched status)
- This is automatically triggered by GetOverview or GetDetails API calls
- Required before any other recipient actions
Reading and Confirmation
- Optionally mark as read (explicit action required)
- Download attachments at any time (triggers AttachmentsDownloaded status)
- Confirm if required (only if
IsConfirmationNeeded = true) - Read status is not required for confirmation
Purging
- Recipients can delete correspondence when no longer needed
- System can also purge correspondence based on retention policies
Error Handling
During Recipient Actions
- HTTP 400 Bad Request: Attempting to read/confirm without fetching first
- HTTP 404 Not Found: Correspondence not available for recipient in current state
Notification Behavior
- Reminder notifications can be sent for unread correspondences
- Notification sending stops once correspondence is marked as read
- Notifications are managed independently of the correspondence status
The system maintains a complete audit trail of all recipient interactions and status changes for compliance and debugging purposes.