Multiple Files per Process

This was one of the first major projects I took on after joining the company, so there was a lot to learn about the world of accounting compliance. This project helped me get up to speed.

FloQast processes could only account for a single file to provide a narrative for a given process. However, customers often use multiple documents to provide complete coverage of that process.

In addition, each document is parsed to extract appropriately tagged controls and their corresponding descriptions. This can result in conflicting descriptions that require correction.

The cost of the limitation wasn't just inconvenience. Working with our customer success team, we traced roughly 32% of processes-related support tickets over the prior two quarters back to document workarounds, and the single-file limit had been cited as a friction point in several enterprise renewal conversations. Fixing it was as much about protecting the account base as it was about feature parity.

To get a better understanding of the issues, I partnered with my PM and customer success to build an inventory of the workarounds customers had invented. Two patterns dominated: merging separate SOPs into a single PDF just to satisfy the upload limit, and splitting one real-world process into several artificial FloQast processes to keep documents separate, breaking reporting in the opposite direction.

Six customer interviews later, the takeaway was clear: they were asking the product to stop flattening the structure of how their documentation actually works.

1. 01

   Multiple files per process

   Let teams upload every document a process actually needs.

2. 02

   Conflict resolution

   Surface conflicting control descriptions and make choosing deliberate.

3. 03

   Versioning

   Track history per process and per document for audit confidence.

I like to work with my team on creating a PRD in a structured form that provides context to the goals (laid out above). That way they can be broken down into the user tasks required to accomplish those goals within a goal-oriented feature matrix. Usually done in Notion

We agreed on success metrics measured in:

First iteration: documents listed within narratives

The first take was to give as much context as we could within the process details page. It seemed obvious to list documents within a narratives section that additional documents could be added to. Users could also view the tagged controls associated with a document by expanding its row.

Conflict resolution: descriptions compared side by side

When multiple documents are parsed, the same control can appear with different descriptions across documents. The initial iteration surfaced these conflicts in a drawer, presenting each description side by side so compliance managers could make a deliberate, informed choice about which description to adopt.

Version history per document

Audit trails are non-negotiable in compliance workflows. The first iteration introduced a per-document history panel logging each upload with a snapshot of that document's file, assignees, and linked controls, giving teams the confidence to trace any change when necessary.

I presented the designs to our design panel, a critique session with the entire design team, and two points shaped the direction from there.

Dropdown overload

The number of actions a user could take on a document became overwhelming for a dropdown, including duplicative actions for a narrative document versus the file itself.

Version history visualization

It was suggested that visualizing version histories, similar to Figma's version history, would be far more legible than a list.

62%

of active enterprise accounts adopted multi-file processes within the first quarter

2.4

average documents per process among adopting accounts

We tracked adoption through product analytics in the quarter following launch, measuring how many active enterprise accounts created at least one multi-file process and how many documents those processes contained. Adoption reaching 62% of active enterprise accounts, averaging 2.4 documents per process, confirmed that teams weren't just trying the feature, but restructuring their workflows around it.