Supporting context01
Granular permission-matrix interface
Administrators configure role and capability combinations across portal workflows
Source · Private production interface with organizational details excluded
Vue 3RBACQuasar
Project archive
Project case study · Frontend
Sahabah Cloud Management Portal
Client and administrator portal interfaces for granular role-based access controls and support-ticket workflows across a cloud-management platform.
Vue 3QuasarTypeScriptPiniaREST APIsRole-Based Access ControlSupport Workflows
2026
Read this case as a
Choose your lens
Outcome-focused delivery
Built connected client and administrator experiences for role-based access and support operations, with shared components and predictable workflow states.
Evidence mode · on
Claims come with context
Each outcome shows its source, related capability, and confidence level. Missing operational data stays visibly unavailable.
Supporting context02
End-to-end ticket workflow
Client submission, administration, status changes, and resolution form one support lifecycle
Source · Private product workflow
Workflow designREST APIs
Unavailable03
Support performance outcomes
Internal support statistics and customer records cannot be published
Source · Client confidentiality
PrivacySupport operations
Skill → proof
Where each capability shows up
Vue 3Granular permission-matrix interface
RBACGranular permission-matrix interface
QuasarGranular permission-matrix interface
Workflow designEnd-to-end ticket workflow
REST APIsEnd-to-end ticket workflow
PrivacySupport performance outcomes
Support operationsSupport performance outcomes
01 / Problem
A fragmented workflow slowed the whole system.
A cloud-management platform needed different permissions for administrators, clients, and organization roles. It also required a structured support workflow that connected client requests with administrative review, status changes, and resolution.
02 / Solution
One product model, expressed clearly at every layer.
I built client and administrator interfaces for configuring and interpreting granular permissions, along with an end-to-end support-ticket workflow. Shared interface patterns keep navigation, access feedback, and ticket state consistent across both portals.
Architecture replay
Walk through the system
Select a layer to inspect its responsibility.
Active layer 1
Vue 3 and Quasar client portal
Vue 3 and Quasar client portal owns the user-facing workflow and consumes a stable contract.
Responsibility stays explicit at this boundary.
Decision log
Centralize permission interpretation
- Context
- Repeating role checks inside individual screens created inconsistent behavior
- Decision
- Mapped permissions through a shared capability layer
- Trade-off
- Added an abstraction layer but made portal behavior more predictable
Decision log
Use one ticket state model across portals
- Context
- Client and administrator screens could otherwise describe the same request differently
- Decision
- Shared the ticket lifecycle and translated it into role-specific actions
- Trade-off
- Required coordination but reduced workflow inconsistency
03 / Challenges overcome
Complexity moved behind durable boundaries.
Permission combinations could become difficult to understand and inconsistent when interpreted separately by individual screens. The support workflow also had to represent changing ownership and status without confusing clients or administrators.
Next step
Want to discuss a similar system?
Share the context and we’ll find a useful first move.