WebStation

The product supported real service operations: service request lifecycles, technician assignment, spare parts handling, attachments, defect codes, and contract-linked flows. This was not a static admin dashboard. The UI had to reflect business policy at every step and remain stable for users working under time-sensitive operational constraints.

The interface behaved differently depending on workflow state, permissions, and local business rules.

• Navigation, actions, and forms changed based on service call status
• Role-based access changed what technicians, dispatchers, and support users could edit or trigger
• Localization affected labels, validation expectations, dates, and market-specific process differences
• Large operational datasets had to stay responsive across list and detail-heavy workflows

I redesigned the service-call detail flow and standardized permission-aware actions across multiple operational screens, including attachments, defect codes, spare parts, fees, and status-driven service workflows.

• I worked on shared behavior for action visibility, editability, validation, and save rules
• I aligned screen behavior with workflow state instead of treating every page as an isolated form
• I improved performance on data-heavy views and reduced frontend duplication across related document flows
• I treated localization and market-specific behavior as implementation constraints from the start, not as a final translation layer

The product’s complexity showed up in very specific interaction rules.

• When a service call was in an open or assignable state, a technician could accept or reject the job, while a dispatcher could assign or unassign subcontractors and update operational fields
• In later closed or checked states, those actions were blocked and document-related controls became read-only
• On attachment- and document-related flows, users could generate artifacts such as warranty certificates or assignment reports only in allowed workflow states
• When the saved status moved into restricted states, those actions were disabled and save attempts surfaced validation feedback instead of letting invalid updates proceed

One of the harder implementation areas was the service-call detail screen, where form behavior changed dynamically based on both workflow status and market configuration.

• Validation rules were not static and could change depending on saved status, accepted state, installer requirements, and network-level configuration
• Fields such as installer name, company, address, phone, email, installation date, and appointment date could become required only under specific combinations of market settings and process stage
• The form layer had to react to business state changes without splitting the screen into multiple versions
• I kept those rules close to the detail flow so the system remained debuggable while still supporting dynamic validation and conditional editability

To reflect the product’s operational scope:

• 5 locales / European markets
• Multiple user roles including technicians, dispatchers, and support-facing users
• Workflow-dependent behavior across service calls, attachments, fees, spare parts, defect codes, and contracts
• Multiple operational screens tied together through shared business state
• Dozens of conditional UI paths driven by status, permissions, and market configuration

One thing I'd improve today is documenting workflows and permission rules earlier. A shared workflow map would reduce ambiguity, simplify implementation, and make future changes easier to maintain.