Working across organisations

When two organisations want to work together digitally, we usually connect their systems. We agree which APIs are available, which data is exchanged and which messages make something happen on the other side. That works, until the collaboration gets closer. Then organisation A has to know more and more about the process of organisation B, and a change on one side breaks something on the other.

The alternative is to share one platform. That removes some of the technical work, but adds another dependency: both organisations have to adapt to the same application, the same data model and often the same way of working.

Either way, digital collaboration is paid for with a piece of autonomy. That is odd. Outside software, we hand over a responsibility all the time without prescribing how the other organisation works inside. A municipality that commissions a structural review doesn’t manage the engineering firm’s process. It needs to know what it asks, what information goes with it, what the result has to meet, and what comes back.

Organisations delegate responsibilities. Software usually connects systems.

Take a building permit application. During the case, the municipality needs a structural review, and hands it to an engineering firm.

The case remains with its owner, the municipality. What crosses the organisational boundary is a case role: a defined responsibility, with access to the information and actions it needs at each stage of the case. The firm takes part in the case without taking over the case itself, and without having to adopt the municipality’s systems. The municipality, in turn, doesn’t need to know how the firm organises its review.

The boundary between the two organisations is the case role. It describes which responsibility is handed over, which information goes with it, what the role may do where the case stands now, and what result is expected. That is far less than sharing a whole process or file, and far more than an API call.

Today the partner carries out the role in the owner’s case, or reads it from its own system; running it as a caseflow of its own on the partner’s side is the next step.

Collaboration is rarely one simple assignment. During the review the firm may need more information. Later a draft advice comes in that still raises questions. Once the advice is final, some actions should no longer be possible at all.

So a case role is not a static contract. The phase the case is in decides what the role can see and do right now. When the phase changes, so does what belongs to the role: other information, other actions. The server enforces that at every step: it is not an agreement on paper, it is a gate.

Once a partner holds the role, its permissions change with the phase as the case moves forward; nobody has to adjust them by hand at each step.

Because the boundary is a role, three things that usually get tangled are kept apart by design:

• Who holds the role. The municipality can hand the review to another firm, or bring it back in-house, without redesigning the case. Outsourcing becomes a decision, not a redesign.
• How the role is carried out. The firm’s people, tools and systems are the firm’s business. Changing them doesn’t change the responsibility it took on.
• The caseflow. The owner can improve its process. A new version doesn’t alter cases already running.

Where a change touches the agreement between the two, both organisations have to accept the new terms; a new firm, too, has to accept the role before it holds it.

Autonomy doesn’t mean working without agreements. It means being free to organise your own work within the responsibilities and limits you have accepted.

The organisations agree what the role must deliver, when it is due, what quality it has to meet, what information it may use, and what happens when the collaboration ends.

CaseFlows ties that agreement to the caseflow that runs. An agreed deadline has to exist in the process, with what happens when it passes, such as the case going back to the permit officer; otherwise the role isn’t connected. And a change to the agreement holds only once both organisations have accepted it.

Collaboration is not just written down. Its limits are enforced.

For the municipality, the engineering firm holds one case role and takes responsibility for one defined result. That doesn’t mean one person at the firm does everything. A project lead takes on the assignment, a specialist does the analysis, a colleague checks it and someone signs the advice.

Today the firm’s own system can already read its role across the boundary, within exactly what that role may see. If a phase doesn’t say what the role may see, nothing leaves the platform.

Where we’re heading: the firm starts a caseflow of its own to fulfil the role it accepted. That caseflow organises the firm’s internal work, while the original case stays with the municipality.

A municipality may work with several engineering firms. A firm may serve several municipalities, and work with its own specialists and suppliers: a laboratory for one part of a review, for instance, which it could hand a role to in exactly the same way.

The ambition is to let these collaborations grow without a new integration project for every new relationship, and without one party having to own the whole chain. Each organisation keeps its own responsibilities, systems and way of working; open specifications describe how they work together.

Today, CaseFlows supports handing a case role to another organisation. Extending that into caseflows that run independently across a wider network is what we are building towards.

The engineering firm may use AI to check the calculations for gaps or prepare a draft, while an engineer decides. How it organises that work is its own decision.

The municipality still deals with the same case role, the same agreed result and the same accountable organisation. AI changes how the work gets done, not who is responsible for delivering it.

Runs today

• Case roles with their own phase, where the server enforces at each moment what a participant may see and do.
• A role held by another organisation, with an agreement both platforms confirm and a protocol that guards the boundary, measured end to end.
• Agreements on result, deadline, quality and ending, where the deadline has to be in the caseflow before the role is connected.
• The partner’s own system reading its role within the limits of that role.
• People from a partner logging in with the account of their own organisation.

Where we’re heading

• A caseflow of its own behind a role, started by the role that comes in.
• A change of phase that reaches the partner’s platform by itself.
• A test case that crosses the boundary on the development environment and continues there as the partner’s own test case.
• Chains that branch further, organisation by organisation.