MEMORANDUM
TO: Management
FROM: Leonid Spektor
DATE: September 1, 2026
SUBJECT: Architectural Assessment & Trade-off Analysis: Citi Desktop Onboarding & Atom Group Provisioning
Executive Summary
Onboarding our application suite to Citi Desktop introduces a structural constraint: the platform supports only one Atom Group per registered application in AppDirectory.
To map our existing 14 production user groups (~767 users across North America) into this paradigm, we have identified two viable onboarding strategies. Both options introduce operational trade-offs between application metadata management and ongoing access governance. Management decision is required to select the path forward.
Key Technical Constraint
Citi Desktop limits each AppDirectory application entry to a single bound Atom Group. Because our current access model relies on 14 distinct functional production groups (e.g., Group A, Group B, Group C), a direct 1:1 mapping within a single AppDirectory application entry is not natively supported by the platform.
Evaluation of Onboarding Options
Option 1: Application-Level Segmentation (14 AppDirectory Applications)
Create 14 separate AppDirectory application entries, where each entry differs solely by its associated Atom Group binding.
- Pros:
- Preserves all 14 existing functional Atom groups as-is without re-provisioning users.
- Eliminates manual user re-keying and bulk entitlement migration risks.
Avoids ongoing dual-maintenance of user group memberships.
Cons:
High application clutter within the AppDirectory catalog.
Violates Atom team platform recommendations.
Increases administrative overhead during global configuration updates or application releases across 14 entries.
Option 2: Group Consolidation (2 AppDirectory Applications: Pilot & Prod)
Consolidate the existing 14 groups into 2 newly provisioned Atom Groups ([PILOT] and [PROD]), mapping to 2 corresponding AppDirectory application entries. This mirrors the approach currently being trialed by the EMEA team.
- Pros:
- Aligns with the Atom architecture teamβs recommended deployment pattern.
Keeps the AppDirectory catalog clean and manageable (2 entries instead of 14).
Cons:
Initial Migration Risk: Requires mapping ~767 users into the new consolidated groups. Manual entry carries a high error rate and will require a dedicated QA validation cycle.
Long-Term Operational Overhead: Future user lifecycle events (onboarding, offboarding, role changes) will require updates across both legacy functional groups and the new Desktop groups.
Redundancy: Legacy functional groups must still be maintained if relied upon outside of Citi Desktop.
Comparative Trade-off Matrix
| Metric | Option 1: 14 AppDirectory Apps | Option 2: Consolidated Pilot/Prod Groups |
|---|---|---|
| Catalog Maintenance | High (14 app records to maintain) | Low (2 app records to maintain) |
| Initial Implementation Effort | Low (configuration-only in AppD) | High (user mapping, entitlement migration, QA) |
| Data Entry / Error Risk | Low (no user migration) | High (~767 users to map without automated tooling) |
| Ongoing User Lifecycle Support | Low (uses existing user entitlements) | High (dual-group maintenance upon joins/moves/leaves) |
| Atom Architectural Alignment | Non-Standard | Standard |
Recommendation & Next Steps
- Short-Term Priority: If Option 2 is selected, we strongly advise against manual user entry. We should engage the Atom support team immediately to request programmatic API or bulk CSV/scripting mechanisms to migrate the 767 users cleanly and reduce QA verification time.
- Decision Required: Management selection between accepting Application Catalog Maintenance (Option 1) versus Ongoing Access Maintenance & Migration QA (Option 2).
Top comments (0)