Business workflow variants: what should be configurable and what needs development?

Before developing automation for a business workflow, define which differences between cases the system must accommodate. Different customers, routes and conditions are not necessarily process defects: sometimes that flexibility is why customers buy from you. A useful specification separates stable rules, configurable values and exceptions requiring a human decision. You can then request an estimate for the range of work, instead of demonstrating one route and discovering that every additional customer requires a code change.

What does the Mercedes example illustrate?

The prepared speech for Daimler’s April 2016 shareholders’ meeting described reducing robot use in some cases because the range of models and options required production flexibility. This is the company’s historical explanation. It does not establish that automation is always slower or people superior at every task, and it does not describe production today.

Our software analogy is limited: a business system must accommodate the kind of variation the company offers. If the customer promise is adaptation, assuming every case follows exactly the same route may be inappropriate. Equally, not every difference warrants a complex mechanism. Before development, establish which differences recur, what they mean and who can decide them. That product decision should precede technology selection.

Collect cases before drawing a screen

Ask operational staff for real cases that can appropriately inform the specification: an ordinary case, an exception and a case that changed during handling. Record the differing input, the rule that changed and the desired outcome. Avoid personal information unnecessary to the exercise. A field list alone is insufficient: cases with identical fields may need a different approval sequence or completion condition.

In a hypothetical quotation system, one difference might be currency, another an approval route and a third a special customer commitment. They should not automatically receive identical treatment. Currency may be a defined value, approval routing a business rule, and a new commitment a decision needed before offering it at all. This is a planning example, not a claim about a customer system we delivered.

Divide variation into three groups

The first group contains values changing within a fixed process: an amount, language or date. The second contains permitted rules with known options, such as extra approval above a business-defined threshold. The third contains cases without an agreed policy yet. Do not ask developers to invent that policy through a code condition. Define who decides and how a case waits without falsely appearing complete.

Record each rule’s source, owner and effective date. For customer-specific exceptions, establish whether they are temporary, which actions they allow and what happens when they expire. Include these distinctions in the technology product specification. This lets you compare development proposals by the behaviour covered rather than screen counts or a general promise that the system will be flexible.

When do you need settings rather than a code change?

A settings interface is useful when an authorised person needs to change a known value or rule often enough to justify it. It also needs permissions, validation and protection against invalid combinations. Not every rule needs a visual editor. For an infrequent change affecting complex calculations, a controlled code change may be simpler to maintain. Ask the supplier to explain its choice using your expected changes.

Check what happens to orders or tasks already underway when a setting changes. Do they retain the old rule, adopt the new one or wait for approval? There is no universal business answer. Retaining the rule version used for an action can help explain its result later. Avoid promising every change without development: even a configurable system needs clear boundaries around the behaviour it supports.

A documented example from our content system

In the Julius website code, content-quality checks define different length thresholds by content type and language. The publishing tool uses the content system’s shared quality check and separately validates file structure and dates. This illustrates explicit rules for known variations. It does not claim those rules suit every website, and it provides no evidence of time savings or search rankings.

The important distinction is that the system neither assumes all content is identical nor creates a separate workflow for each article. It receives a defined structure and selects checks through known characteristics. In another business, examine the same question: which differences can be expressed through data and rules, and which actually change the process? Base that decision on your cases rather than building a general-purpose mechanism before it is needed.

Test combinations and an exception route

Request acceptance checks covering important differences and selected combinations. Examples include a particular customer type with an above-threshold request, or a rule change following initial approval. Establish the expected outcome and the person qualified to confirm it. Include an unsupported case: the system should stop clearly, retain necessary information and route it to an appropriate person rather than choose an unapproved default.

If AI classifies incoming requests, separate its suggested classification from permission to act. Test ambiguous input and correction of a mistaken classification too. Our guide to choosing AI developers expands on model evaluation and responsibility. For a conversation with Julius about software development, bring three differing cases and one expected change. They provide a concrete starting point for discussing necessary flexibility and development boundaries without accidentally fixing the part of the business that needs to keep changing.