Data Sync
Designing a scalable system to synchronize and map external data into xMatters
Role: Lead Designer
Scope: System architecture, interaction model, integration framework
Context: Multi-phase initiative, starting with ServiceNow
Problem Space
Many customers managed users, groups, sites, and devices in external systems and relied on custom APIs to sync data into xMatters. This approach was manual, fragile, and difficult to audit, making it hard to keep records aligned.
There was no unified approach to:
- Object mapping
- Property logic
- Conflict resolution
- Sync visibility
We began with ServiceNow, but the broader goal was to create a scalable foundation for multi-source integrations.
The Core Design Challenge
The core challenge was designing a reusable sync architecture.
We needed to define:
- A canonical sync model
- Flexible mapping and override logic
- Clear conflict handling
- A framework extensible to future systems
Differences across object types, update rules, and failure states made this a systems-level problem.
The real challenge wasn’t just moving data - it was bringing clarity to a complex architecture.
My Role & Approach
The PM brought an early vision and low-fidelity wireframes. We aligned on a preliminary direction, and I partnered closely with engineering to define the architecture and ship iteratively.
I:
- Defined the core interaction model for mapping and configuration
- Structured the information architecture
- Designed reporting and history visibility
- Helped break the feature into incremental releases
We deliberately avoided a “two-year big launch.” Instead, we shipped in increments and this allowed the team to deliver value every few months while evolving the system architecture.
Core Decisions
Design for Extensibility from Day One
Although ServiceNow was the initial data source, the system was built to scale beyond it. We defined a reusable sync framework that:
- Supported multiple external systems
- Abstracted property mapping logic
- Standardized configuration patterns
- Established a consistent reporting model
Make Sync Behavior Explicit
Rather than obscuring backend complexity, we surfaced it. The system made clear:
- Overwrite vs. conditional update rules
- Default value and override behaviour
- Mapping logic for various object types
- Authentication failures and partial sync states
This reduced ambiguity and improved administrative confidence in high-risk operations.
Design for Visibility & Operational Trust
Sync operations can easily become opaque.
We prioritized transparency through:
- A configuration dashboard with clear status states
- Per-configuration history views
- Detailed reporting tables
- Row-level error explanations
- Exportable audit logs
This shifted sync from a “black box” process to an observable, controllable system capability.
Ship in Structured Iterations
Rather than waiting for a complete feature set, we defined a stable architectural backbone and delivered in phases. Afterwards we added reporting and refinements incrementally and scoped advanced features (estimated record previews, expanded group/site sync) for future phases.
This enabled progress without compromising scalability.
Outcomes
- A scalable integration foundation
- Reduced manual data management
- Greater confidence in automated sync processes
- A reusable model for future external systems
Daria Ershova
Data Sync
Designing a scalable system to synchronize and map external data into xMatters
Role: Lead Designer
Scope: System architecture, interaction model, integration framework
Context: Multi-phase initiative, starting with ServiceNow
Problem Space
Many customers managed users, groups, sites, and devices in external systems and relied on custom APIs to sync data into xMatters. This approach was manual, fragile, and difficult to audit, making it hard to keep records aligned.
There was no unified approach to:
- Object mapping
- Property logic
- Conflict resolution
- Sync visibility
We began with ServiceNow, but the broader goal was to create a scalable foundation for multi-source integrations.
The Core Design Challenge
The core challenge was designing a reusable sync architecture.
We needed to define:
- A canonical sync model
- Flexible mapping and override logic
- Clear conflict handling
- A framework extensible to future systems
Differences across object types, update rules, and failure states made this a systems-level problem.
The real challenge wasn’t just moving data - it was bringing clarity to a complex architecture.
My Role & Approach
The PM brought an early vision and low-fidelity wireframes. We aligned on a preliminary direction, and I partnered closely with engineering to define the architecture and ship iteratively.
I:
- Defined the core interaction model for mapping and configuration
- Structured the information architecture
- Designed reporting and history visibility
- Helped break the feature into incremental releases
We deliberately avoided a “two-year big launch.” Instead, we shipped in increments and this allowed the team to deliver value every few months while evolving the system architecture.
Core Decisions
Design for Extensibility from Day One
Although ServiceNow was the initial data source, the system was built to scale beyond it. We defined a reusable sync framework that:
- Supported multiple external systems
- Abstracted property mapping logic
- Standardized configuration patterns
- Established a consistent reporting model
Make Sync Behavior Explicit
Rather than obscuring backend complexity, we surfaced it. The system made clear:
- Overwrite vs. conditional update rules
- Default value and override behaviour
- Mapping logic for various object types
- Authentication failures and partial sync states
This reduced ambiguity and improved administrative confidence in high-risk operations.
Design for Visibility & Operational Trust
Sync operations can easily become opaque.
We prioritized transparency through:
- A configuration dashboard with clear status states
- Per-configuration history views
- Detailed reporting tables
- Row-level error explanations
- Exportable audit logs
This shifted sync from a “black box” process to an observable, controllable system capability.
Ship in Structured Iterations
Rather than waiting for a complete feature set, we defined a stable architectural backbone and delivered in phases. Afterwards we added reporting and refinements incrementally and scoped advanced features (estimated record previews, expanded group/site sync) for future phases.
This enabled progress without compromising scalability.
Outcomes
- A scalable integration foundation
- Reduced manual data management
- Greater confidence in automated sync processes
- A reusable model for future external systems
Daria Ershova
Data Sync
Designing a scalable system to synchronize and map external data into xMatters
Role: Lead Designer
Scope: System architecture, interaction model, integration framework
Context: Multi-phase initiative, starting with ServiceNow
Problem Space
Many customers managed users, groups, sites, and devices in external systems and relied on custom APIs to sync data into xMatters. This approach was manual, fragile, and difficult to audit, making it hard to keep records aligned.
There was no unified approach to:
- Object mapping
- Property logic
- Conflict resolution
- Sync visibility
We began with ServiceNow, but the broader goal was to create a scalable foundation for multi-source integrations.
The Core Design Challenge
The core challenge was designing a reusable sync architecture.
We needed to define:
- A canonical sync model
- Flexible mapping and override logic
- Clear conflict handling
- A framework extensible to future systems
Differences across object types, update rules, and failure states made this a systems-level problem.
The real challenge wasn’t just moving data - it was bringing clarity to a complex architecture.
My Role & Approach
The PM brought an early vision and low-fidelity wireframes. We aligned on a preliminary direction, and I partnered closely with engineering to define the architecture and ship iteratively.
I:
- Defined the core interaction model for mapping and configuration
- Structured the information architecture
- Designed reporting and history visibility
- Helped break the feature into incremental releases
We deliberately avoided a “two-year big launch.” Instead, we shipped in increments and this allowed the team to deliver value every few months while evolving the system architecture.
Core Decisions
Design for Extensibility from Day One
Although ServiceNow was the initial data source, the system was built to scale beyond it. We defined a reusable sync framework that:
- Supported multiple external systems
- Abstracted property mapping logic
- Standardized configuration patterns
- Established a consistent reporting model
Make Sync Behavior Explicit
Rather than obscuring backend complexity, we surfaced it. The system made clear:
- Overwrite vs. conditional update rules
- Default value and override behaviour
- Mapping logic for various object types
- Authentication failures and partial sync states
This reduced ambiguity and improved administrative confidence in high-risk operations.
Design for Visibility & Operational Trust
Sync operations can easily become opaque.
We prioritized transparency through:
- A configuration dashboard with clear status states
- Per-configuration history views
- Detailed reporting tables
- Row-level error explanations
- Exportable audit logs
This shifted sync from a “black box” process to an observable, controllable system capability.
Ship in Structured Iterations
Rather than waiting for a complete feature set, we defined a stable architectural backbone and delivered in phases. Afterwards we added reporting and refinements incrementally and scoped advanced features (estimated record previews, expanded group/site sync) for future phases.
This enabled progress without compromising scalability.
Outcomes
- A scalable integration foundation
- Reduced manual data management
- Greater confidence in automated sync processes
- A reusable model for future external systems