Handling a record that belongs to two processes — a deal that becomes a project, a ticket that becomes a bug — is a structural question. Duplicating it is the wrong answer; connecting is usually the right one. Why duplication is tempting Each process wants its own phases, fields, and owners, which
To give clients access to their own data, the scoping has to be a permission rather than a filter. A filtered view can be changed by the person looking at it; a permission cannot. What is at stake Getting this wrong exposes one client's information to another. * A
To handle multiple currencies, the first decision is structural: the currency symbol is set at field level, so a single field cannot hold two currencies meaningfully. Why currency handling goes wrong Amounts are stored casually and then have to be compared. * Values typed as text with a symbol, so nothing
To reduce the number of fields on a form, you rarely need to remove data. Most long forms are long because they ask for things the system could derive, connect, or hide. Where the length comes from Forms grow one reasonable addition at a time. * Fields asked of everyone that
To get a process out of someone's head, you build it alongside them while they work rather than interviewing them about it. Processes described from memory are always tidier than the real thing. Why documentation projects fail Asking someone to describe a process produces the version they think
Deciding how to handle legacy data is one of the first questions in any implementation, and one of the most commonly overthought. Bringing everything is rarely necessary and often harmful. Why importing everything backfires Historical data carries the structure and the quality of the system it came from. * Inconsistent records
To test a process before rolling it out, you need real data and real users. A test with invented records tells you the build works, not whether the process does. Why tests pass and rollouts fail The test conditions differ from reality in exactly the ways that matter. * Clean test
Deciding what to automate and what to leave manual has a practical test: automate what is repetitive, rule-following, and cheap to correct. Leave manual what carries authority or is irreversible. Why automating the wrong thing backfires Automation amplifies whatever a process already is, including its mistakes. * A judgement encoded
Learning to handle exceptions in a process is what separates a system people use from one they work around. A process with no route for exceptions forces every unusual case outside it. What happens without an exception route The exceptions do not disappear. They just stop being visible. * Unusual cases
Good naming conventions for internal systems are invisible when they work and expensive when they do not. Names are read far more often than they are written. What inconsistent naming costs It is a small tax paid constantly by everyone except the person who chose the names. * Two tables with
Deciding how many phases a process should have comes down to one test: does the phase change who is responsible or what happens next? If neither, it is a field value rather than a phase. What too many phases costs Each column adds a place for work to sit and
Deciding which fields should be required is a balance. Too few and records arrive incomplete; too many and people enter something arbitrary just to proceed. What over-requiring produces A mandatory field someone cannot answer honestly will be answered dishonestly. * Placeholder values entered to get past a form * Guessed data