Work Understanding: Integrations
Objective. Read the integrations screen as the inventory of data sources that feed the process picture, judge whether coverage is adequate, and escalate connector scope and setup rather than promising it.
Integrations show which systems feed observed work into the app. They answer 'do we have the data sources that make the process picture complete?' - because coverage of sources determines how trustworthy every finding is.
See it in the demo
What this screen answers
The customer question is: which systems are we drawing work from, and is that enough to see the whole process? This is a configuration screen. Sales people use it to discuss what feeds the analysis without over-promising connectors; CSMs use it to validate that the sources needed for a process are actually connected before trusting any finding about it.
The value is honest coverage: a process that crosses five systems but only has two connected will have an incomplete picture, and the gaps will hide exactly the handoffs and waiting the app is meant to find.
The task
- Open the integrations screen from the overview.
- Read which sources are connected and map them to the processes in scope - does the app see every system the work actually touches?
- Identify coverage gaps: a connected source list is only adequate relative to the processes you want to analyse.
- Treat connector availability, scope and setup as confirm-with-product and specialist work to escalate - never assert that a specific system integrates or how, from the demo.
Describe sources by their role in coverage, not invented connector names or setup steps.
How to read it
Read integrations as the ceiling on completeness: findings can only be as complete as the sources feeding them. The classic misread is trusting a process analysis while a system that work flows through is not connected - the resulting picture looks whole but has blind spots exactly where the unconnected system sits.
A connected source is not the same as full coverage of that source, and a long connector list is not the same as the right connectors for the process in question. Read coverage relative to the specific process, not as a general 'yes we are integrated'.
Honest limits
This screen does not prove a customer's systems will integrate, nor what effort that takes - the demo's sources are illustrative. Connector availability, scope, and setup effort are product and implementation questions.
Confirm with product which systems integrate for a customer, at what coverage, and what setup is required. Never promise an integration or a timeline from this screen. Position it as the check that keeps findings honest - adequate source coverage before trusting a process picture - and escalate the real connector scoping to a specialist.
Interpretation check
Integrations are the ceiling on completeness: a process picture is only as whole as the sources feeding it. A system the work touches but that is not connected creates blind spots; connector scope and setup are confirmed with product and escalated.
In the field
An RCM process that spans an EHR, a clearinghouse and a billing system cannot show real waiting if only billing is connected - so confirming source coverage is the prerequisite to any days-in-AR claim.
Practical task
On the demo integrations screen, pick one process, list the systems its work plausibly touches, and note which would need to be connected - and which you would escalate to product - before you would trust a complete picture of that process.
Self-check
A process analysis looks complete, but one system the work uses is not connected. What is the risk?
The picture has a blind spot exactly where the unconnected system sits - often the handoffs and waiting the app is meant to surface. Judge coverage relative to the specific process before trusting the finding.
Is a long list of connected sources proof of good coverage?
No. Coverage is only adequate relative to the processes in scope, and a connected source is not the same as full coverage of it. Map sources to the actual work, not to a general 'we are integrated'.
A prospect asks if their core system integrates. Can you confirm from this screen?
No. Connector availability, scope and effort are product and implementation questions. Confirm with product and escalate the scoping; never promise an integration or timeline from the demo.
How does this screen keep findings honest?
It shows whether the sources feeding a process are adequate, so you check coverage before trusting the analysis rather than reading a confident-looking but partial picture.
Verified vs demo. Screen is live in the demo at /#/integrations; exact connectors and controls are SME-validation-pending and illustrative, and which systems integrate, at what coverage and effort for a customer, must be confirmed with product.