The Future of Citizen Service Orchestration in Canada

The dominant model of digital government is the portal. Government organizations build websites where residents can find information and complete transactions. The portal is an improvement over paper and phone for residents who know what they need, can navigate digital systems, and have reliable internet access.

But the portal model has a fundamental limitation. It puts the burden of orchestration on the resident.

When a newcomer arrives in Canada, they do not need a better portal. They need health coverage, a SIN, a bank account, school registration for their children, language training, employment services, and income support if they qualify. These are not separate needs that happen to be administered by separate organizations. They are a connected set of needs that a person in a particular life situation has all at once.

The portal model requires that person to identify each need separately, find the right organization for each one, navigate each organization's digital system, provide their information multiple times, and track the status of multiple separate processes simultaneously. The orchestration burden falls entirely on the person least equipped to carry it.

The future of digital government is transferring that orchestration burden from the resident to the system.

What Service Orchestration Means

Service orchestration means that when a resident interacts with one government touchpoint, that interaction can trigger, inform, and connect to other services and processes that the resident needs, without requiring the resident to initiate each one separately.

This is not science fiction. Versions of it already exist. When a child is born in some provinces, the birth registration automatically triggers an application for the Canada Child Benefit, an enrollment in the provincial health system, and a notification to the school district. The parent does not need to contact four separate organizations. One registration sets multiple processes in motion.

The question is how far this model can be extended, and what it requires to extend it.

The Architecture of Orchestration

Service orchestration at scale requires three things that Canada does not yet fully have: a common identity layer, interoperable data systems, and a consent framework that residents trust.

The common identity layer is the foundation. For a resident's interaction with one service to inform their interaction with another, those services need to know they are dealing with the same person. This requires a verified digital identity that works across federal and provincial systems, not just within a single department or jurisdiction.

Interoperable data systems mean that when one service has verified a piece of information about a resident, that verification can be recognized and relied upon by other services, with the resident's consent. Income verification from the CRA should not need to be repeated for every provincial benefit program. Immigration status verified by IRCC should not need to be reverified by every provincial service. The information exists. The systems to share it, securely and with appropriate consent, need to be built.

The consent framework is what makes this trustworthy. Residents need to understand what information is being shared, with whom, and for what purpose. They need meaningful control over that sharing, including the ability to withdraw consent. And they need to trust that the system will honor their choices. Without a consent framework that residents actually trust, orchestration becomes surveillance, and the political and social license for it disappears.

What Orchestration Makes Possible

With these foundations in place, several things become possible that are currently very difficult.

Proactive service delivery means government reaches out to residents with services they are entitled to, rather than waiting for residents to find and apply for them. A family that qualifies for the BC Family Benefit should not miss out because they did not know it existed. A senior who qualifies for the Guaranteed Income Supplement should not fail to receive it because they did not apply. Orchestrated systems can identify likely eligibility and initiate contact, with resident consent, rather than relying entirely on resident-initiated applications.

Life event navigation means that when a resident experiences a significant life event, birth, death, job loss, disability, arrival in Canada, the system can recognize that event and surface the connected services that are relevant, rather than requiring the resident to know in advance what to look for. A newcomer who registers with a settlement organization should be able to have relevant provincial and federal services surfaced to them at that point, not discovered piecemeal over months.

Continuous eligibility management means that as a resident's circumstances change, their access to services can be updated automatically rather than requiring a new application for every change. A parent whose child turns six should not need to reapply for child benefit programs that change at that age. The system should know, and update accordingly.

What Stands in the Way

The barriers to citizen service orchestration in Canada are significant but not insurmountable.

Jurisdictional complexity is the most fundamental. Federal and provincial responsibilities are divided in ways that create natural friction for orchestrated services. Health is provincial. Immigration is federal. Income support is a mix. Building orchestration across jurisdictional lines requires intergovernmental cooperation that is genuinely difficult to sustain.

Legacy systems are a practical barrier. Many government systems were built decades ago, are not designed for interoperability, and are expensive to modify. The investment required to make legacy systems capable of participating in orchestrated service delivery is substantial.

Privacy law creates constraints that need to be navigated carefully. PIPEDA and provincial privacy legislation place real limits on information sharing between government organizations. Building orchestration that respects these limits requires careful legal design, not just technical design.

Public trust is the ultimate constraint. Canadians will only accept orchestrated government services if they trust that their information is being used appropriately, that they retain meaningful control, and that the system is accountable when things go wrong. Building that trust requires demonstrated commitment to privacy and resident rights over a sustained period.

Where MyCanada Fits

MyCanada is an early-stage orchestration layer. It does not yet connect to government systems in ways that enable automated service delivery. What it does is navigate: helping residents understand what services exist, what they qualify for, and how to access them.

The navigation layer is the first step toward orchestration. Understanding the landscape of services, structured and validated, province-aware, searchable in plain language, is a prerequisite for connecting those services in ways that serve residents automatically.

We are building MyCanada with the orchestration future in mind. The data structures, the service relationships, and the resident journey model that underlie MyCanada are designed to connect to government systems as those systems develop the interoperability that orchestration requires.

The future of citizen service in Canada is not a better portal. It is a system that knows what you need before you have to ask, surfaces it when you need it, and handles the administrative complexity so you do not have to. Building that future is the work of a generation. The navigation layer is where it starts.