16.2 Evaluating Use Cases for Business Logic

Domain 3 of AB-410 — Build business application logic and automation at 40–45% of the exam — is dominated by scenario questions of the form: a requirement, four tools, pick the right one. The winning strategy is a fixed decision order: configuration before automation, automation before code. Always choose the least complex tool that fully meets every stated requirement — and read the scenario for the one constraint that disqualifies the simpler options.

The Business Logic Toolbox

Business rules in detail

A business rule combines conditions with actions. Scope decides where it executes: scoped to a specific form or all forms, it runs in the browser for instant feedback; scoped to the table, it also executes server-side on every save, regardless of which app or API wrote the data. Available actions: set column value, clear column value, set business required, set visibility, enable or disable (lock/unlock), show error message for validation, and recommendations. Hard limits: conditions read only the current row's columns, and multi-select choices, file, and language columns are not supported.

Business process flows in detail

A business process flow (BPF) renders a chevron bar across the top of a model-driven form that walks users through stages (for example, Qualify, Develop, Propose, Close), each containing steps (columns to complete or actions to take). A single BPF can span up to 5 tables, with up to 30 stages and 30 steps per stage, and supports conditional branching. BPFs guide the process rather than enforce data correctness — pair one with business rules for stage-aware requirements, such as requiring Estimated Revenue only in the Propose stage.

Classic workflows and plug-ins

Background (asynchronous) and real-time (synchronous) workflows still exist in long-lived environments; AB-410 expects awareness that they are legacy and that new work defaults to cloud flows. Plug-ins are .NET classes registered on event-pipeline steps (pre-validation, pre-operation, post-operation) that run inside the transaction — choose them only when declarative options genuinely cannot do the job: multi-row transactional math, logic that must roll back with the save, or performance-critical validation on bulk operations.

Worked Scenarios

Scenario 1 — Instant form validation. Requirement: when an account's Relationship Type becomes Customer, Credit Limit must become visible and required immediately. Answer: a business rule scoped to the form (or the table). Zero automation, instant feedback, no run history to monitor. A scheduled flow here is the classic over-engineering trap.

Scenario 2 — Approval outside Dataverse. Requirement: discounts over 20% need manager approval in Microsoft Teams, and the quote cannot proceed until approved. Answer: a cloud flow with an approvals action. Approvals, Teams, and Outlook live outside Dataverse — no business rule or column type can reach them.

Scenario 3 — Transactional integrity. Requirement: when an invoice line is saved, the remaining budget on the cost center must decrement inside the same transaction, and any failure must roll the entire save back. Answer: a plug-in. A cloud flow is asynchronous — it fires after the commit, so a failed flow leaves committed, inconsistent data. Rollups are hourly. Only in-transaction logic guarantees the invariant.

Scenario 4 — Guided process. Requirement: new support agents must follow a consistent Triage, Investigate, Resolve sequence, with required steps per stage and management visibility into where every case sits. Answer: a business process flow on the Case table, optionally with business rules making stage-specific columns required.

Scenario 5 — Legacy awareness. Requirement: an existing real-time workflow stamps a reference number on case creation. Answer: leave working legacy logic alone, but meet new equivalent requirements with a cloud flow for background work or a plug-in when truly transactional. Recognize the mapping: real-time workflow means synchronous legacy; background workflow means asynchronous legacy.

Trap Patterns the Exam Repeats

• A flow for what a rule does free: hiding or showing columns, setting required state, simple value defaults on a form — business rules do this instantly with no monitoring overhead. Any answer proposing a scheduled flow for form UX is wrong.
• Code for what config does: proposing a plug-in to multiply two columns when a calculated or formula column does it natively, with no code, no deployment pipeline, and no maintenance burden.
• A rollup for real-time needs: a rollup can be up to an hour stale, so the phrase must be current the moment the child row saves kills the rollup answer.
• A calculated column for aggregates: calculated columns see the current row and its parents — never a sum over children.
• A business rule for integration: rules cannot call APIs, send mail, or touch other systems — that is flow or code territory.

When two answers both seem plausible, find the requirement word that breaks the tie: immediately on the form points to a business rule; approval, another system, or scheduled points to a cloud flow; inside the transaction or must roll back points to a plug-in; guiding users through stages points to a business process flow.