The same rule in three places
If the same validation is implemented in your app, in your integration and in your ERP, you have already made a placement decision. You made it three times, in three sprints, with three different teams, and nobody recorded which copy is the one that counts. That last part turns reasonable redundancy into an audit finding nine months later.
A business rule has four places it can sit in a multi-system estate. It can live in the user interface, where a required field or a disabled submit button stops someone before they get further. It can live in the application's own configuration, in a Power Apps business rule or a Fusion value set. It can live in the integration layer, in the flow that carries the record between systems. Or it can live in the system of record, in the server-side validation every caller has to pass.
Each step down that list buys enforcement and costs you speed. A rule in the interface gives immediate feedback and one person can change it in an afternoon, and any integration writing to the same table never sees it. A rule in the system of record applies to every caller, including the nightly load and the consultant running a data fix, and changing it means a change request, a regression pass and a release window.
What each placement is actually for
Interface rules exist for the person typing. They catch a bad record early, they explain why in words a human understands, and they keep the support queue short. Their weakness is that they only run while somebody is looking at a screen. The moment a record arrives through an API, a migration or a bulk edit, the rule does not fire, and nothing announces that it was skipped.
Integration-layer rules are the ones I see added under pressure. A record failed downstream, someone put a condition in the flow, the error stopped repeating and everyone moved on. That copy covers everything on that one route and nothing on any other. Two years later there are four routes into the same object and the condition sits on one of them, which is the argument for keeping integration contracts small and explicit.
Rules in the system of record are the only ones that hold when nobody is watching. A validation in Oracle Fusion Cloud applies to the requisition a buyer types, the one loaded from a spreadsheet and the one posted by a maintenance system at two in the morning. The price is that changing it touches all those paths at once, so the change gets scheduled instead of made, and teams who need a different answer this quarter build their own copy somewhere looser.
The threshold that moved in two places out of three
A building products manufacturer I reviewed last year had a capital requisition rule. Anything above fifty thousand needed a second approver from finance. It was written into the Power Apps requisition form, into the Power Automate flow behind that form, and into the approval configuration in Oracle Fusion Procurement. Three copies, all agreeing, for about two years.
Finance dropped the threshold to twenty thousand for the new fiscal year. The form and the flow belonged to the same Power Platform team and both changed inside one sprint. The Fusion approval rule belonged to the ERP team, who had a release calendar, a change freeze through quarter end and a separate ticket queue. That change sat for eleven weeks. Nothing looked broken, because every requisition raised through the form still picked up the second approver.
The maintenance system posted requisitions straight into Fusion on a schedule, and it had never touched the form. For eleven weeks, every requisition between twenty and fifty thousand on that path went through on a single approval. Internal audit pulled them out of a sample in March. Nobody had made a mistake you could point at in a ticket. The rule had three homes, only the copy nobody could see was doing real enforcement, and that copy was the slowest to move.
Duplication on purpose and duplication by accident
Duplicated rules are usually correct. A required field on the form and a matching constraint in the database are both good design, because the two copies do different jobs. The form copy exists so a person finds out in two seconds rather than two days. The database copy exists so the rule still holds when the person is a scheduled job with a service account.
The test I use in a review is whether anyone can tell me why each copy exists. When the answer is that the interface copy gives feedback and the system of record copy gives enforcement, the duplication was a decision and somebody can maintain it. When the answer is that the integration team hit an error last spring and added a condition without telling the platform team, what you have is a second rule that happens to agree with the first one this week.
The difference shows up at change time. Deliberate copies get written down together, usually in the same design note, and whoever edits one goes looking for the others. Accidental copies get discovered by the person debugging why two records with identical data came out differently. Rules that quietly stop agreeing with each other are the normal end state for duplication nobody registered.
Start from who must never be able to break it
My placement test starts with naming everyone who must never be able to violate the rule, written out as an actual list of actors. If that list includes the nightly integration, the data migration and the admin with a loader tool, the rule belongs in the system of record and nothing else is sufficient. If it contains only the person filling in the form, the interface copy does the whole job.
The answer changes with the kind of rule. A segregation of duties control, a tax registration requirement, a retention period, an approval limit named in a financial control document: those have to hold for every caller, because the question an auditor asks is about every caller. The problem of one person wearing four hats does not get easier when the actor turns out to be an integration user.
A workflow preference sits in a different category. Sales wants a close date before an opportunity reaches negotiation. Procurement wants a preferred supplier picked first. Those are real rules, they change twice a year, and enforcing them in the system of record means every tweak becomes an ERP release. Put them where the owning team can change them, and accept that a bulk update will eventually step around them.
Write down the copies before you add a fourth
For any rule you can name, the useful thing to produce is one line per copy covering where it lives, who owns that layer and what happens when it fires. I ask for it in design reviews and it takes twenty minutes for a rule that has been live for years. The gaps appear straight away, most often in the form of a copy nobody in the room will claim.
Then pick which copy is authoritative and say so in writing, where the next team will actually look. Every other copy is a convenience that can be wrong without being dangerous, and saying that plainly is what survives a handover. Asking who owns the exception in an integration design gets you to the same answer from the other direction.
The next time somebody asks you to add a validation to a flow because a record failed downstream, ask which existing copy already covers that case and what happens to each copy when finance changes its mind in November. If nobody in the room can answer either question, what you are really adding is a fourth thing to keep in sync.
