CASE STUDY · B2B SAAS · SECURITY ORCHESTRATION
Self-Serve Integrations
Read time:
10 min
Client:
Enterprise SOAR Platform
Industry:
Cybersecurity
Timeline:
16 Weeks
Removing the engineering bottleneck from customer onboarding, so the people responsible for migrations could actually complete them.
CONTEXT
A platform built for orchestration, gated by its own setup
The product lets security teams connect and orchestrate data across the tools they already use: ticketing systems, ITSM platforms, threat feeds, and more. Integrations are how a customer wires those tools together so that incident and case data flows automatically between them.
The problem lived at the very start of that journey. Before a customer could orchestrate anything, their data had to be migrated and mapped into the platform, a step that depended entirely on us, not on them.
THE PROBLEM
Every migration was gated by engineering and licensing
Whenever a customer onboarded, or whenever new data needed to be added to an existing setup, the migration couldn't be self-served. It required backend involvement and depended on a specialized license being provisioned first. The onboarding team had no path to do it themselves.
That created three compounding costs that got harder to ignore as the customer base grew:
It didn't scale
01
I design for users who operate under pressure and process high volumes of information. Discovery, analysis, execution. I've owned workflows end-to-end at enterprise scale.
It pulled engineering off the roadmap
02
I design for users who operate under pressure and process high volumes of information. Discovery, analysis, execution. I've owned workflows end-to-end at enterprise scale.
It slowed time-to-value for the customer
03
I design for users who operate under pressure and process high volumes of information. Discovery, analysis, execution. I've owned workflows end-to-end at enterprise scale.
DISCOVERY
What the people doing the work actually said
I ran discovery as a lean, qualitative pass: semi-structured interviews with IT Administrators, Security Analysts, and stakeholders who served as proxies for the people doing migrations day-to-day, supplemented by support tickets and a first-hand audit of the live flow.
Four themes converged across every conversation:
"We're highly dependent on our backend team to configure and troubleshoot data sync setups."
IT Administrator
"We don't have a straightforward way to verify app compatibility; it usually involves testing and seeing if it works."
Security Analyst
"Field mapping is often confusing and error-prone. A more intuitive interface with clear guidance would help."
Migration Engineer
Across those themes: backend dependency, no visibility into compatibility, painful instance setup, and confusing field mapping. The thread running through all four was the same: the people responsible for migrations couldn't trust the flow to work without routing something through engineering.
A NOTE ON RESEARCH CONSTRAINTS
Direct access to external customers was limited for this project, so I interviewed internal proxies and supplemented with support tickets and a flow audit. It's qualitative, internally-sourced research rather than a clean external-user study, a constraint I'd name openly. A v2 iteration would validate these findings with external customer interviews before the next major change.
WHO I WAS DESIGNING FOR
Technically capable people blocked by a structural gap
The primary users were the people who run customer onboarding and data migration: Implementation Specialists, Solutions Engineers, and Customer Success Managers during the onboarding phase, and for larger enterprise clients or especially complex transfers, specialized Data Migration Engineers.
This audience is technically capable and comfortable with configuration, but they are not backend engineers. Under the old model, every migration they owned still had to be routed through backend engineering and gated by license provisioning. The people responsible for onboarding could not actually complete onboarding on their own. The design goal was to give them a self-service path they could run and trust without escalating to engineering for each transfer.
THE REFRAME
The real cost was not the sync. It was everything before it
KEY INSIGHT
Users spent more effort preparing an integration than configuringone. Discovering compatible apps, locating an instance, re-entering credentials, switching between tools. The actual sync configuration was the small part. All the friction lived in the preamble.
This reframed the project from "make the sync screen better" to "remove the dependency and the prep work that surround it." That shift drove every subsequent decision.
CURRENT STATE
A journey map that showed where friction actually lived
Mapping the existing flow for a representative goal (connecting two tools so incident data flows between them) surfaced the pattern clearly:
STAGE
ACTION
THINKING
PAIN
Discover
Opens integrations area
"How do I even connect this?"
No visibility into compatible apps
Search
Looks for the app
"Is this one even supported?"
Can't discover available connectors
Configure
Needs an instance
"I don't have one set up."
Forced out of the workflow entirelyc
Validate
Re-enters credentials
"Didn't I already do this?"
Duplicate effort across steps
Return
Comes back to start
"Now where was I?"
Lost context after switching tools
The architectural picture was equally clear: the steps that forced a backend handoff were not user-facing problems. They were structural ones, baked into how the system was built. That's where the redesign had to intervene.
SERVICE BLUEPRINT
Making the system dependency visible
USER ACTION
FRONTSTAGE
BACKEND SYSTEM
Open integrations
Integrations UI
None
Search App
Search results
App catalog service
Select App
Compatible-apps list
Compatibility engine
Select Instance
Instance dropdown
Instance management
Create Instance
Instance modal
Authentication service
Configure Mapping
Mapping screen
Sync engine
Because the real problem was a system dependency rather than a surface-level UX issue, I mapped the experience against the backend systems behind it. This gave me a clear picture of where handoffs lived, and gave engineering a shared artifact to work from.
INFORMATION ARCHITECTURE
Collapsing four external dependencies into one continuous flow
The redesign collapsed what had been an external, multi-system dependency into one self-contained, self-service path that the onboarding team could complete without leaving the product or waiting on anyone else.
Integrations → Backend team → App catalog → Instance manager → Authentication → back to Integrations
Select app → Configure connection → Map fields → Set trigger → Name and review → Job created
EXPLORATIONS
Three directions and why two were rejected
Before committing to a direction, I evaluated three approaches against the same criteria: discoverability, cognitive load, and implementation cost.
Separate install flow
Keep installation and setup as a standalone area, separate from the main integrations flow.
✗ Rejected: [replace: what it cost in cognitive load / context switching]
OPTION B
Embedded app catalog
Surface available apps inside the existing flow without restructuring the underlying navigation.
✗ Rejected: [replace: what it failed to solve about the prep-and-handoff problem]
OPTION C · SHIPPED
Unified discovery
One place to discover, connect, and configure, with no external steps or system handoffs.
✓ Chosen: only approach that eliminated prep work and the dependency together
SCOPE & KEY DECISIONS
What we cut, and why each cut made sense
A unified flow could have sprawled. What kept it shippable in one quarter was deciding what not to build yet, and being able to defend each decision.
Connection testing as an automatic property, not a manual step
In the old flow, users had to test connectivity and re-enter credentials as a standalone task. In the redesign, connection testing happens automatically once source and destination details are filled in. Two clear outcomes: success, or a detailed error view with an error code. If the automatic test fails, users can fall back to a manual entry option covering URL, username/password, or token. Validation is built into the step rather than bolted on after it.
Compatibility as a first-class, filterable property
Rather than letting users discover incompatibility by failing, I surfaced a sync-compatible check directly in the catalog and installed-apps views, as a badge and a filter. The pattern was modelled on the platform's existing filters so it read as native, not added-on. Users see what is eligible before they invest any effort.
Type-safe field mapping with custom value support
Field mapping enforces a type constraint: only fields of the same data type can be connected. This prevents a class of silent configuration errors that previously surfaced only at runtime. Alongside this, custom value mapping handles real-world inconsistencies between systems, for example mapping "Yes" in one tool to "True" in another, without requiring the source data to be cleaned first.
Source-only for v1
I scoped the first release to support apps as a source of data only, not yet a target. This covered the most common migration need and let us ship and learn before taking on the added complexity of bidirectional sync.
App/instance-level compatibility; action-level deferred
A finer-grained, action-level compatibility check was valuable but expensive to build. I pushed it explicitly to a later phase so v1 could ship a coherent experience first, rather than a partial one.
Reuse, don't reinvent
Creating an instance inline reused the existing pattern from the automation builder rather than inventing a new flow. Agent-based instances, which are not compatible with sync, were excluded from selection to prevent dead-end configurations. Less to learn; less to break.
THE SOLUTION
A five-step job creation flow the onboarding team owns end to end
he module was rebuilt from scratch: UX, UI, and frontend. The Data Sync Job creation flow is the core of the experience. Each step has a clear and bounded job.
Source and destination setup
The user selects the source product (the tool they are migrating data from) and the destination (Cyware's platform). Connection is tested automatically once both are filled in.
Success moves the user forward. An error surfaces inline with a code and a detailed view, plus a manual fallback: URL, username/password, or token. No leaving the flow to debug.
Field mapping
The user maps source fields to their destination counterparts. Only fields of matching data types can be connected, preventing configuration errors that would otherwise only surface at runtime
Handles real-world inconsistencies between systems. For example, a field that stores "Yes" in one tool maps correctly to "True" in another, without requiring any upstream data cleaning.
Job trigger
The user configures when and how the job runs. Schedule options cover: once, daily, weekly, or monthly. For teams with more granular needs, a cron expression can be entered directly.
Job details
The user names the job and adds an optional description. Job name is required. Keeping this step late in the flow means users name something they already understand, rather than something they are still configuring.
Review and create
A summary of the full configuration: field mappings, job details, trigger settings. Every field is editable inline at this stage, so the user can correct anything without navigating back through previous steps. Once confirmed, the job is created.
POST-CREATION
The job details page: visibility and control after creation
Once a job is created, the user lands on the Job Details page. This is where the job lives after it is running
JOB DETAILS
CREATED BY
LAST MODIFIED
LAST RUN
User Name
Date & Time
Date & Time
View Run History
Terminate Job
Two actions matter most here: viewing run history, which gives the onboarding team a record of what the job has done, and the ability to terminate the job if something is wrong. Both are surfaced without additional navigation.
DESIGN SYSTEM
Extending the existing system, not forking it
Every component decision was made to keep the new work additive rather than divergent.
Reused components: search, dropdown, modal, table, badges, and the create-instance-on-the-go pattern from the automation builder.
New, purpose-built components: a sync-compatible badge, a sync-compatible filter (modelled on the platform's existing filter patterns), an instance-status indicator, and the error detail view for failed connection tests.
Extending rather than forking meant less for engineering to build, less for users to learn, and a module that would scale as more connectors were added, rather than becoming a one-off exception.
BEFORE VS. AFTER
The same goal, four fewer steps to reach it
STEPS
BEFORE
AFTER
Steps in core flow
8
5 (structured, self-contained)
Context switches
4
0
Validation points
2 (manual, repeated)
1 (automatic, with fallback)
Field mapping guardrails
None
Type-safe mapping enforced
Who completes it
Backend engineering
Onboarding team, self-serve
The experience shifted from backend-dependent, hard to discover, and fragmented across tools. The redesigned experience is self-service, discoverable, and a single continuous workflow.
IMPACT
What changed, and what I'd measure next time
The engineering dependency was removed by design. The step that previously gated every customer migration no longer exists in the flow. The onboarding team completes it themselves, without escalating to backend engineering.
It shipped as a full rebuild. UX, UI, and frontend, not an incremental patch on the existing module.
Positive qualitative signal in review. Reviewers specifically responded to the ability to select and install compatible apps without backend support, and to compatibility checks surfaced upfront rather than discovered through failure. Setup was described as faster and lower-effort than the previous script-and-middleware process. This is feedback, not instrumented measurement, but it is tied directly to the problems the project set out to solve.
If I revisited this, the first addition would be instrumentation: time-to-first-integration, self-serve completion rate, and migration-related support volume, so the next iteration could prove the outcome quantitatively rather than through feedback alone.
ON MEASUREMENT
The module wasn't instrumented at launch, so there are no post-release usage analytics to point to. What follows is concrete and structural, not quantified. I will name that distinction clearly.
REFLECTION
The research constraint taught me the most. Designing for users I could not reach directly meant leaning on internal proxies, and proxies are useful right up until the point where they are not. They were reliable on the mechanics of the flow, the steps people took and where they got stuck, but they could only approximate the emotional texture of onboarding a real customer under deadline. I learned to treat proxy research as a strong hypothesis rather than a finding, and to be honest in the work itself about which was which.
The thing that surprised me was where the friction actually lived. I went in assuming the sync configuration was the hard part, because that is the part that looks complex. Mapping the whole system showed me the opposite: the configuration was small, and almost all the pain sat in the preparation around it, discovering compatibility, finding an instance, re-entering credentials, switching tools and losing your place. That reframe changed the entire project. It is a lesson I have carried forward, which is that the obvious problem is rarely the expensive one, and the system view is what tells you the difference.
And if I did one thing differently, it would be instrumentation from day one. I can describe the structural outcome with confidence, but I cannot yet prove it with numbers, and that gap is on me. Next time I would define the measures before the first screen: time to first successful job, self-serve completion rate, connection error frequency, and migration-related support volume.