Skip to content

Commit c5a2a5a

Browse files
authored
adr for communication with delegatees (#1343)
1 parent f0785be commit c5a2a5a

File tree

1 file changed

+93
-0
lines changed

1 file changed

+93
-0
lines changed

doc/adr/004-notify-delegatee.md

Lines changed: 93 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,93 @@
1+
# Delegation notification for application instance access - User discovery and navigation
2+
3+
- Status: Accepted
4+
- Deciders: Signing Task Force
5+
- Date: 2025-12-06
6+
7+
## Result
8+
9+
- A1: Send correspondence message to delegatee's inbox with direct link to application instance, in addition to existing instance message under relevant "Aktør".
10+
11+
## Problem context
12+
13+
When implementing user-delegated signing flows, users are granted read access to application instances they need to sign. However, the current inbox structure creates a significant user experience problem for delegatees trying to find and access these instances.
14+
15+
Currently, when a user (delegatee) is granted read access to an application instance, the only way to access the instance is through an instance message that appears under a different "Aktør" (the instance owner) in their inbox. This creates several usability issues:
16+
17+
1. Delegatees cannot find the application instance in their usual work-in-progress section
18+
2. They must know to look under a different "Aktør" section
19+
3. They must know which specific "Aktør" owns the instance
20+
4. The discovery path is non-intuitive even for developers with internal knowledge
21+
22+
User testing with internal team members showed conclusively that the current approach is too difficult to navigate, leading to the expectation of support cases from end users who cannot find delegated instances.
23+
24+
## Decision drivers
25+
26+
- B1: Reduce user confusion and support burden
27+
- B2: Provide intuitive discovery path for delegated instances
28+
- B3: Maintain existing functionality for instance owners
29+
- B4: Work within constraints of correspondence service architecture
30+
- B5: Ensure consistent notification experience (inbox + email/SMS)
31+
32+
## Alternatives considered
33+
34+
- A1: Send correspondence message to delegatee's inbox with direct link to application instance
35+
- A2: Modify inbox structure to show delegated instances in main work-in-progress section
36+
- A3: Add notification banner or widget to highlight delegated instances
37+
- A4: Keep current approach and provide user education/documentation
38+
39+
### A1 - Correspondence message to delegatee (CHOSEN)
40+
41+
Send a correspondence message directly to the delegatee's inbox containing:
42+
- Clear indication that they have been delegated access
43+
- Direct link to the application instance
44+
- Context about what action is required
45+
46+
This is sent in addition to the existing instance message under the relevant "Aktör".
47+
48+
### A2 - Modify inbox structure
49+
50+
Restructure the inbox to display delegated instances alongside user's own work-in-progress instances, potentially with special visual indicators.
51+
52+
### A3 - Status quo with documentation
53+
54+
Maintain current approach and provide user guidance on how to navigate to delegated instances.
55+
56+
## Pros and cons
57+
58+
### A1 - Correspondence message to delegatee (CHOSEN)
59+
60+
- **Good**: Supports B1 - provides clear, discoverable path to delegated instances
61+
- **Good**: Supports B2 - delegatees receive direct notification in their primary inbox view
62+
- **Good**: Supports B3 - does not modify existing functionality for instance owners
63+
- **Good**: Supports B4 - works within existing correspondence service capabilities
64+
- **Good**: Supports B5 - creates consistent notification experience across channels
65+
- **Neutral**: Creates duplicate pathways to the same instance
66+
- **Bad**: Increases number of messages in delegatee's inbox
67+
68+
### A2 - Modify inbox structure
69+
70+
- **Good**: Supports B2 - would provide most intuitive user experience
71+
- **Good**: Supports B1 - eliminates confusion about where to find delegated instances
72+
- **Bad**: Does not support B4 - would require significant changes to correspondence service architecture
73+
- **Bad**: Potential impact on B3 - structural changes might affect existing workflows
74+
- **Bad**: High implementation complexity affecting multiple teams and services
75+
76+
### A3 - Status quo with documentation
77+
78+
- **Good**: Supports B3 - no changes to existing functionality
79+
- **Good**: Supports B4 - no technical implementation required
80+
- **Bad**: Does not support B1 unless the end users somehow find the documentation
81+
- **Bad**: Does not support B2 - maintains unintuitive discovery path
82+
- **Bad**: Does not address underlying UX problem
83+
84+
## Decision rationale
85+
86+
The decision favors A1 (correspondence message to delegatee) based on user testing results and the need for an immediate, practical solution that works within existing system constraints.
87+
88+
Key factors in the decision:
89+
1. **User testing evidence**: Internal testing demonstrated that even technically knowledgeable users struggled with the current approach
90+
2. **Practical implementation**: Solution works within existing correspondence service capabilities without requiring architectural changes
91+
3. **Immediate relief**: Provides direct path to delegated instances without waiting for larger inbox restructuring
92+
93+
While A2 (modifying inbox structure) might provide the most elegant long-term solution, it would require extensive cross-team coordination and architectural changes. A1 provides immediate value and can coexist with future inbox improvements. Note that this has been discussed with "Arbeidsflate".

0 commit comments

Comments
 (0)