Platform Overview
iCura is structured as a set of connected products sitting on top of one shared data model, rather than as a single monolithic application. This page explains how the pieces fit together.
The shared data model
Every product — Core, WorkOps, CRM, 360, Operational Intelligence, the Family App and Finance & Billing — reads from and writes to the same underlying data model. A change made in one product is immediately visible to every other product that depends on it.
In practice, this means a rota change in WorkOps updates cost forecasts visible in Operational Intelligence and compliance coverage tracked in 360, without any manual synchronisation step.
Roles and permissions
Access in iCura is role-based. Each user is assigned a role (for example, Care Worker, Registered Manager, Regional Director, Compliance Lead), and that role determines exactly which records, actions and reports they can see. This applies uniformly across every product, including the AI layer — see Security & Data Handling for detail on how this is enforced.
The Composable Workflow Engine
Most configuration in iCura happens through the Composable Workflow Engine rather than custom development. This is where your organisation defines:
- Forms and fields specific to how you record care.
- Approval chains for actions above a defined risk or cost threshold.
- Automations that move work forward — for example, a completed assessment automatically triggering a review task.
- Dashboards surfaced to specific roles.
Where AI fits
The AI layer sits across all of this rather than inside any single product. It reads the same permission-scoped data every user can see, reasons over it, and either surfaces an insight, drafts an action, or — for anything above a risk threshold — routes to a human for approval. See AI Decision Support and AI Governance for more detail.
Where this runs
iCura is built on Microsoft Azure. See Microsoft Azure for the specific services involved, and Architecture for how the layers are structured end to end.