Connecting organisations through data

From Data Drop to Data Network

My initial concept, Data Drop, was a lightweight portal with an unauthenticated, one-time upload link. It would have been a quick win, but mapping its workflow revealed that it would move the email problem further down the chain: links buried in inboxes, no persistent activity record and resubmissions still needing coordination.

The Data Drop would have been a quick win but an incomplete solution.

I proposed Feeds instead: a whole new area in the product with authenticated users, separate organisations and persistent relationships between partners. This was a larger product increment, but one that addressed the whole workflow, making persistent connections between organisations and opening a path to a broader network strategy.

Flexibility for complex submissions

When we spoke with users and looked at their existing Quantemplate workflows, we could see that a submission was rarely uniform: Premium and Claims might arrive as separate tabs, files, or from different organisations, each needing different pipeline logic.

I introduced subsections to represent these distinct streams within one submission. Feed owners define subsections, and submitters assign uploads to the appropriate one. Using the wayfinding principle of progressive disclosure, the interface walks them through the process, step-by-step.

Using wayfinding principles, I navigated users through the process of assigning their data to the right subsection.

Feeds 5: Submitting and receiving data Uploading data to a Feed to send to a partner organisation, using subsections to separate Premium and Claims data. Watch on YouTube

Roles for humans and robots alike

I modelled permission levels around the way our clients divided responsibility. Owners and managers needed to configure Feeds, connect with partners and oversee the process. Submitters only needed access when it was time to upload data, while read-only users needed visibility to use Feeds data in pipelines.

I introduced the concept of a ‘Robot User’ to surface automation capabilities across the platform and make them auditable.

Looking at our permissions model, I realised that we needed a way to run automations without a user present, and have those runs tracked in the history. When the Robot User has access to a Feed, they can take the data from it, run a pipeline they have access to and output it to a dataset they’ve been given write permission on.

Trusted setup in under a minute

Initiating a partner connection required just their contact’s email. We used the domain to find their organisation or begin creating it. I researched and proposed a logo.dev integration to populate organisation names and logos automatically, reducing setup effort and making requests more recognisable. Admins on each side approve the connection, with all events tracked in a new admin panel.

A lot of complexity behind the scenes, enabling simplicity in the product.

Admins can also create reusable schedules to centrally manage request frequency. Research revealed that feeds often shared a cadence but followed different contract dates. I made start and end dates properties of a Feed, rather than a schedule, allowing requests to stop at contract end without affecting other feeds using the same schedule.

All that’s required to set up a new Feed is to add subsections, search for a partner and connect an existing schedule. In under one minute you can be requesting data from your trading partners.

Feeds 2: Set up a feed How to set up a Feed, add subsections and connect a schedule. Watch on YouTube

The full picture, at a glance

Both parties retain an immutable, versioned record of submitted data. User avatars and organisation domains identify the people and companies behind submissions, building trust.

I redesigned the Feed repository as a management dashboard, showing which Feeds are complete, waiting for data or overdue; this real-time view of inventory replaces manual tracking in spreadsheets. Configurable reminders chase outstanding submissions automatically.

Visible connections between Feeds and pipelines help managers understand what each submission will trigger and what the automation is still waiting for.

Connecting the whole data chain

Feeds support incoming data, outgoing distribution and onward sharing. An insurer can distribute data to reinsurers, while a broker can receive and pass on the original submission. Each organisation can connect its own processing pipelines while retaining a shared, auditable source record. This uniquely allows us to surface the full data Chain of Custody.

Data Chain of Custody How insurers, MGAs, TPAs, brokers and reinsurers exchange bordereaux data through Quantemplate’s network, with a transparent, permanent view of where data came from, how it was processed and who it was shared with. Watch on YouTube

The Feeds lay the architectural groundwork for the big vision: automated data flows across the industry.

We mapped out further Use Cases on this support page.