Interactive selector
Connector selection tool: prioritize the systems that matter to the workflow
Score connection readiness before adding integrations for their own sake.
Introduction
What this selector is for, and what it is not.
Connector counts are a poor proxy for capability. A platform that connects to seven hundred systems and a workflow that needs three connected correctly are different things, and the second one is what determines whether anything useful happens.
This tool scores connection readiness across the same five operating dimensions, applied to the specific systems a workflow depends on. The question it is trying to answer is not how many integrations are available, but whether the ones this workflow actually needs are authorized, reachable, permissioned, and usable.
Connected has to mean usable. OAuth succeeding is not the same as the records being reachable, and a catalogue entry existing is not the same as the fields the workflow needs being exposed. Scoring this before building is considerably cheaper than discovering it afterwards.
The problem
The problem this is trying to surface.
Integration decisions get made from availability rather than from need. A catalogue is presented, everything on it looks useful, and connections are established because they can be. Each one carries permission surface, maintenance, and a dependency, and only some of them serve a workflow anybody is running.
The more expensive failure is treating authorization as completion. OAuth succeeds, a green tick appears, and the connection is reported as operational. Whether the specific records the workflow needs are reachable, whether the credential has permission to see them, and whether the fields are exposed through the supported API are separate questions that often have different answers.
The third problem is that connection priority rarely follows customer or revenue value. Long-tail breadth is easier to demonstrate than depth on the three systems a paying workflow depends on, so effort drifts toward the catalogue and away from the cohort that actually produces outcomes.
You're likely here because
- You are choosing which systems to connect first and everything looks equally important
- A previous integration authorized successfully and still could not do the job
- Nobody is certain which permissions the workflow actually requires
- Connector count is being used as a proxy for whether something will work
How the inputs work
What each input does to the result.
Every input is something you supply, so the result is only as good as the honesty of the answers. Knowing how each one is weighted is what makes the output arguable rather than opaque.
Step 01
Score trusted data and record coverage
Rate how consistently the team can find current, authoritative records for connector selection. Everything else depends on this: automation reading uncertain data produces confident wrong answers faster.
Step 02
Score workflow clarity
Rate how explicitly the triggers, owners, next actions, and completion states of connector selection are defined. Ambiguity here is the most common reason automation stalls after the demo.
Step 03
Score systems connected
Rate how much of the workflow can move without copy/paste or manual reconciliation. Every unconnected step is a place where a person is currently acting as the integration.
Step 04
Score outcome measurement
Rate how well activity in connector selection can be tied to cycle time, conversion, quality, or revenue. Without this you cannot tell afterwards whether a change helped.
Step 05
Score governance and exception handling
Rate how explicit permissions, approvals, escalation paths, and human review are. This determines how much of the workflow can safely run without a person in the loop.
Step 06
Read the lowest score, not the average
The average is a summary; the lowest dimension is the constraint. That is where the next piece of work belongs, regardless of how much more appealing the other four look.
Implementation path
What to do with the result.
- 01
Score each dimension from observed evidence rather than intent. Optimistic input produces a score that agrees with you and helps nobody.
- 02
Take the lowest dimension. That is the constraint on connector selection, and work anywhere else will be absorbed by it.
- 03
Define one measurable target outcome for connector selection — a cycle time, a conversion step, or an exception rate — and record its current baseline.
- 04
Fix the workflow and control gap at the constraint before expanding automation. Automating around an unresolved constraint relocates the problem rather than removing it.
- 05
Connect the systems that step depends on, and verify what the workspace actually reads before building anything on top of it.
- 06
Re-score after one full cycle. If the same dimension is still lowest, the work did not land and the next attempt should be different rather than larger.
Controls
Controls that matter.
Control 01
Scores taken from observed evidence, not from how the team would prefer to be described
Control 02
One named owner per dimension, so a low score has somebody accountable for moving it
Control 03
Human review kept in front of any customer-facing or consequential step in connector selection, regardless of the score
Control 04
A baseline recorded before changes, so the re-score is a comparison rather than an opinion
Examples
How teams read this in practice.
Patterns that recur when this is scored honestly, and what each one is actually telling you.
Authorized but not usable
A connection completes OAuth and the workflow still fails, because the credential cannot see the records it needs. Authorized, reachable, and usable are three different states and only the third one matters.
Connected everything, used three
A workspace establishes eleven connections and one workflow depends on three of them. The other eight are permission surface and maintenance with no workflow behind them.
Field not exposed
The system connects and the specific custom field the workflow depends on is not available through the supported API. Discovering this during scoring costs minutes; discovering it mid-build costs a sprint.
Breadth before depth
Effort goes to catalogue coverage while the three systems a paying workflow depends on remain shallowly integrated. Prioritizing the cohort tied to real outcomes is the higher-leverage choice.
Limitations and considerations
What this tool cannot tell you.
- This is a directional self-assessment, not a measurement. Most of its value is in the conversation the scoring produces rather than in the number it returns.
- Results are only as honest as the inputs. Teams routinely rate workflow clarity higher than their own exception volume supports.
- The five dimensions are weighted equally, which is a simplification. In some businesses governance or data coverage dominates everything else.
- A high score does not mean automation will succeed. It means the operating foundation is less likely to be the reason it fails.
- The result reflects one workflow. Scoring connector selection across a whole company produces an average that hides the specific constraint worth acting on.
- Nothing here substitutes for the security, privacy, and approval requirements that apply to your business.
FAQ
Questions about this tool.
How should we score this honestly?
From evidence rather than intent. Look at exception volume, how often records turn out to be stale, and how much of the workflow currently requires a person to move data between systems. Teams that score from how the process is meant to work get a number that agrees with them and helps nobody.
What does the score actually mean?
It is a directional read on whether the operating foundation is likely to be the reason an automation effort fails. It is not a prediction of success and should not be presented as one.
Why does the lowest dimension matter more than the average?
Because the lowest dimension is the constraint. Work invested in the other four gets absorbed by it, which is why teams with strong tooling and unclear workflow definitions keep buying software that does not help.
Why not just connect everything available?
Every connection carries permission surface, maintenance, and a dependency. Connections without a workflow behind them add risk and effort without adding capability, and they make the genuinely important ones harder to see.
What does connected actually need to mean?
Authorized, reachable, fetched or synchronized where required, available to the runtime, provenanced, and usable for the specific job. OAuth succeeding is the first of those, not the last.
Which systems should we connect first?
The ones a workflow you are actually running depends on, in the order those workflows produce value. Catalogue breadth is easier to demonstrate and rarely the constraint on an outcome.
Start with ARIA
Ask ARIA to act on the result.
A score is a starting point. Describe the outcome you want and ARIA works out the capabilities, systems, and data needed to get there.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Connect what the workflow needs, in the order it needs it.
Describe the workflow on the public ARIA path, or browse the connection catalogue to check what is available for the systems you run.