One record, three truths: about forms in low code BPM tools

A salesperson opens a client's record to check what they talked about a month ago and whether there's an upsell opportunity. An accountant opens the same record because she needs the bank account number, VAT status and payment history. A field technician opens it on his phone in the parking lot outside the client's building, because he wants to know one thing: what equipment is on site and what was done to it last.

Three people, one record - and one form, designed to fit everyone's needs.

Which means no one's.

Systems don't die because they don't work

After years of ERP implementations I've learned one thing: a system almost never loses on features. It loses on screens.

Research on automation rollouts shows this rather brutally. When users start working around a system, the implementation has failed regardless of whether everything technically works. Shadow processes appear: unofficial workarounds, notes on the side, spreadsheets "just for our team". Failed implementations see adoption 40–60 percent lower than successful ones - and low adoption feeds a spiral: less usage means less feedback, less feedback means no fixes, no fixes mean even less usage.

The spreadsheet next to the system isn't born out of laziness. It's born the day someone scrolls through thirty fields for the third time in a row to find one. Nobody declares a rebellion. Someone just sets up a spreadsheet "to actually work in", because it has what they need, in the order they need it. Six months later the company has two sources of truth and a meeting where someone asks why the data in the system doesn't add up.

It adds up fine. Nobody enters it there anymore.

Where the one-size-fits-all form comes from

I'm not pulling this out of thin air - I've designed forms like this myself. The mechanism is always the same.

During an implementation, the data model gets the most attention. Rightly so: fields, relations, validations - that's the foundation. The problem is that the screen comes afterwards, as a derivative of the model. The object has forty fields, so the form has forty fields. Someone during analysis added "we could use a field for shipping notes" - and it lands on the screen too, for everyone, forever. Completeness starts to impersonate usefulness.

Low-code platforms, paradoxically, make this worse. Since the form was clicked together and looks tidy, it's easy to assume it's good. Analyses of low-code limitations keep coming back to exactly this thread: the visual editor lulls design vigilance, and applications come out functionally complete yet exhausting in daily use. The tool sped up building the screen - but it didn't ask, on anyone's behalf, who will be looking at that screen and why.

And the answer to that question is the same in every company: different people, for different things.

A screen isn't a view of the database. It's a view of someone's work

This is the inversion we built Opero's forms around: the object and the form are two separate things.

The object - say, a client or a service order - is one. It has its fields, relations and validations, and that doesn't change. But there can be many forms on that object: separate ones for viewing, editing and creating a record, assigned to specific roles. The salesperson, the accountant and the technician get three different screens on the same record. The data stays one.

Back to our three people.

The salesperson sees the contact history at the top, open sales opportunities and notes from recent conversations. The financial section? It's there, collapsed at the bottom - sometimes he wants to check whether a client pays on time before proposing a bigger contract, so there's no reason to hide it. But he doesn't have to fight through it every time he opens the record.

The accountant sees bank accounts, VAT status, payment terms and the list of unsettled invoices. The sales conversation history is of no interest to her, and on her form it simply doesn't exist. Her edit screen lets her correct billing data - and only that, because the sales fields on this form aren't writable. That's not just a matter of convenience. It's also fewer opportunities for someone to accidentally overwrite something another department is responsible for.

The technician gets the shortest form of the three: an address with navigation, the on-site contact person, the equipment list and the last three visits. Everything readable in two minutes on a phone, standing in a parking lot. The rest of the client record doesn't concern him, so it isn't there.

The key point: none of these people got a "trimmed-down view of the full form". Each got a form designed from their work, not from the table structure.

A form that reacts

Separate forms per role are the first step. The second is a form that reacts to what happens inside it.

In Opero, every field and section can carry a visibility condition. The invoicing section appears only once the client is marked as a company. The "complaint reason" field exists only for complaint-type requests. The form starts with a few questions and unfolds along with the answers, instead of greeting the user with a full wall of fields, most of which don't apply today.

That's a topic for a separate article, so I'm only flagging it here. But the mechanism is the same: the screen follows the situation, not the database schema.

What this changes about implementations

There's one more consequence of separating the form from the object, less obvious, and to me just as important: changing a screen stops being a change to the system.

When the form is stitched tightly to the data model, every screen tweak means touching something running in production - so nobody wants to do it, and forms freeze in the shape they had on go-live day, even though the company has long since started working differently. When the form is its own thing, it can be fixed a week after accounting reports that something's missing. And they will report it - because the first version of every form is a guess. The difference lies in whether that guess can be corrected cheaply.

Which brings me back to the research from the beginning, because there's one more finding in there that didn't surprise me: teams are most effective at torpedoing systems nobody asked them about during design. In one described case, a customer service department got automated ticket routing, judged its decisions poor and worked out their own manual re-routing - the automation worked flawlessly on a technical level and achieved nothing. Role-based forms won't fix that by themselves. They only lower the cost of reacting to what people say. You still have to talk to them.

A good screen won't fix a bad process

To be clear: I'm not claiming forms solve implementations. If nobody in the company knows who approves an order, three polished screens won't change that. The process has to be settled first - on paper, in a conversation, wherever.

But the reverse is just as true and said out loud far less often: a bad screen will kill even a well-arranged process. It will just do it slower and more quietly. One spreadsheet at a time.

That's why when I look at an implementation - ours or anyone else's - I don't start with the feature list. I start by asking what the screen looks like that a specific person sees twenty times a day. Because that's where - not in the process engine - it gets decided whether the system will actually be used.

One record. As many truths as there are people working with it. A system that can't handle that will have one truth in the database and another one - in spreadsheets it will never see.