rashmiux

Fixing a critical integration to arrest bleeding sales pipeline

Import

Create

Unmapped

Mapped

Ignore

Connect

MAP client

MAP site

MAP Asset Class

other configurations

Map clients from HaloPSA to SuperOps

You can choose to map existing clients, create new clients, and ignore client records

Last fetched on March 10, 2026 at 04:00 am

Import

Unmapped

Save

create in superops

Create

client in halopsa

Acme Corporation

Beta Innovations

Gamma Solutions

Delta Technologies

Epsilon Enterprises

Zeta Industries

Eta Systems

Theta Holdings

Iota Group

Kappa Dynamics

Lambda Strategies

Mu Consulting

client in superops

Choose a client

Beta Innovations

Gamma Solutions

Delta Technologies

Epsilon Enterprises

Zeta Industries

Eta Systems

Theta Holdings

Iota Group

Kappa Dynamics

Lambda Strategies

Mu Consulting

Ignore

...

Showing 1-100 of 820

The ecosystem

MSPs - PSA & RMM

Managed Service Providers (MSPs) typically rely on two core systems: a PSA to manage customers and operations, and an RMM to monitor and manage devices. This project focused on helping customers already using HaloPSA (PSA) seamlessly adopt SuperOps RMM through a robust integration experience.

what is the problem space

How might we enable a user integrate Halo PSA and SuperOps RMM ?

What is the existing flow

Existing workflow consists of steps to sync the two platforms

What is not working

Users are missing steps - L2 Tickets are accumulating

Sales use the flow for demos - this is the pitch - the integration is being compared to the market leader

MAJOR BLOCKER

The back end architecture of competitor is different and has less steps

This integration was built for granularity and has infinite mappings

Demos and sales are affected

STEP ONE

Analyse the existing flow for frictions

WHAT ARE WE TRYING TO SOLVE

How might we help users establish a proper sync between the two platforms ?

How might we help sales team show a demo that closes the deal ?

How might we help the first user see the value quickly in a demo ?

40%

Reduced demo environment setup time

30%

Integration-related support tickets after launch

30%

Customers completing a successful HaloPSA integration

Role

Senior and Sole Product Designer

Owned research, product design, and created quality heuristics that guided our the integration.

Team

4 Engineers, 1 APM, 1 Head of Engineering

What are the problems ahead

Challenges & Design Heuristics

Enterprise complexity

Designed for two enterprise systems with different data models, where every onboarding required reconciling organizations, sites, assets, and configurations.

Dependency-heavy workflow

Every mapping decision affected the next. A mistake early in the flow could prevent assets from synchronizing successfully.

infinite mappings

Field mappings weren't finite. Every asset type introduced its own schema, making the configuration space grow continuously as the product evolved.

Time-to-value

Enterprise customers wanted deep customization, but requiring every configuration upfront delayed the first successful sync.

Multiple stakeholders

The same integration supported Solutions Engineers during sales demos, Implementation teams during onboarding, Customer Success during troubleshooting, and MSP administrators during ongoing operations.

Technical constraints

Some seemingly simpler UX solutions conflicted with backend architecture, API sequencing, and synchronization logic. The experience had to work with—not against—the system.

Designing for scale

The onboarding architecture needed to support future asset types, mappings, and synchronization scenarios without requiring fundamental redesign.

Designing for failure

Users frequently skipped mappings, causing synchronization failures and support tickets. The workflow needed sensible defaults and recovery paths instead of assuming perfect configuration.

integration framework

The existing integration framework had to be preserved. This included bulk mappings. And flows with create and ignore options.

exploration # 1

Replicate the competitor

This could not be done - the integrations were global and not granular and the back end architectures were completely different.

key interface decisions

Progressive Complexity

Use case 1: Allow customization for MSP technicians

Use case 2: Help sales team show value to lead quickly

How do we balance both ?

Use case 3: This will allow MSPs to map critical mappings first - this will let the assets be pushed. They can map the data to be displayed much later

key interface decisions

Surfacing criticality

This will ensure the critical mapping is done. So the assets are pushed during the integration

reflection # 1

Designing for constraints

This was a very complex tech heavy product. The constraints was high.

reflection # 2

Trade-offs are inevitable

When operating in constraints and existing framework, the trade-offs will be high and the solution might not be the most intuitive. So embracing it is necessary.

key interface decisions

Auto suggestions

Since the number of mappings were infinite, auto suggestions supported by back end would mean reduced manual work. This was tech initiated solution.

MAJOR FRICTION # 1

System Status visibility

The existing flow did not surface enough information for users to be aware of what was happening

MAJOR FRICTION # 2

Micro-interactions

The micro-interactions had umpteen frictions.

MAJOR FRICTION # 3

Not designed for scale

This was an MVP version and not designed for scale

key interface decisions

Push back on product ask

Major change suggested by product was combing two steps since technicians were missing site mapping. Contract APIs could not be written as this was a dependency flow.

Create