Best practices

These recommendations come from how Logic Composer behaves: what is fixed after the first save, what users see when a rule fails, what can and cannot be deleted, and what runs on every call. Follow them and your logic stays easy to read, safe to change and quick to run.

Naming

• Choose names you can keep. Name and Project are fixed after the first save, and so are Block Type, a recipe’s table and a few other fields. Renaming means recreating the artifact and rebinding everything that uses it. See Working in Composer.
• Name blocks and flows after what they answer or do. Quote Discount, Case SLA Due Date, Submit Order for Approval. Avoid technical prefixes and version numbers in names.
• Name validations as the message users read. In a recipe, a failed validation shows the block’s name, and a failed validation set shows the names of its failed rules, one per line. The requested delivery date must be after the order date is a good name; ValidateDates2 is not. Names allow letters, numbers, spaces, hyphens and underscores only.
• Name inputs and outputs in plain words. Callers bind inputs by name, the Run dialog shows them, and AI agents read them when you expose logic as an MCP tool.
• Use the Docs tab. The Description appears in the Run dialog and helps AI agents choose the right tool.

Structure and reuse

• Blocks answer, flows act. Keep calculations, decisions and checks in logic blocks, which never change data, and keep reading-then-writing in logic flows. A block can then be reused safely from recipes, flows, business processes and expressions.
• One block, one question. A focused block is easier to test and reuse. If a formula grows hard to read, split part of it into another block and call it with Run Logic Block.
• Pick the block type that matches the decision. Same questions for every case: decision table. Different questions per case: decision tree. One value: formula. See Logic blocks.
• Do not hard-code values that change. Put thresholds, rates and switches in configuration values and user-facing text in localized resources. One change then applies everywhere.
• Organize projects by business capability, such as Sales Pricing or Case Management, not by artifact type. A project is the unit you deploy.
• Guard once, at the logic itself. Put “who can run” and “only when” rules in a precondition instead of repeating checks in every caller. It applies to every caller, including Dataverse actions and AI agents.

Decision logic

• Order decision table rows from specific to general. The first matching row wins.
• Always add a catch-all. A decision table needs a last row with empty conditions, and every decision in a tree needs a default branch. Otherwise a case you did not foresee fails the run.
• Design for empty values. An empty number counts as 0, and an empty Yes/No counts as No. Decide whether empty should pass or fail, and check it explicitly with Null or Not Null when it matters. See Empty values.
• Choose Return First Validation Error deliberately. Turn it off for forms, so users see every problem at once. Turn it on when later rules only make sense after earlier ones pass, and order the rules accordingly.

Testing

• Run every block and flow after every change with the Run dialog: a typical case, every boundary value, empty optional inputs, and a case that should hit the catch-all.
• Test as a real user. The Run dialog runs as you, and preconditions are checked for the user who runs the logic. An administrator may pass checks an end user fails.
• Test flows that change data outside production. Their steps run for real.
• Keep repeatable tests. Use the Logic Assurance agent to keep test cases with expected results and rerun them after each change.

Performance

• Read only what you need. On the Data tab, choose only the columns your logic uses, filter queries tightly, and use Single multiplicity when you expect one row.
• Let preconditions fail early. Who can run rules are checked before any data is read, so unauthorized calls cost little.
• Stop at the first failure when that is enough. With Return First Validation Error on, later rules do not run.
• Cache stable settings. Use Cache with TTL for configuration values that rarely change, and Do Not Cache only when a change must be seen immediately.
• Keep recipe work light. Logic in a recipe’s Validation and Before stages runs while the user waits for the save. Use Applies When: so items run only when relevant, and move work that can wait to the After stage with Async on. See Logic recipes.

Maintainability

• Treat inputs, outputs and exposure as a contract. Others bind to input and output names. Turning on Expose as Dataverse Action cannot be undone, and actions do not allow lists, so decide before you save. Expose as MCP Tool can be switched off at any time. See AI and API exposure.
• Fix problems before you save. Composer does not save artifacts with problems, so finish a change in one sitting or in small, valid steps.
• Change logic in development, deploy it as managed. Managed projects are read-only, which keeps test and production identical to what you built. Use the Logic Fabric CLI to move projects.
• Let dependencies guide clean-up. Logic Fabric refuses to delete artifacts that are still in use. When a delete is refused, find and change the users first; do not work around it. See Dependencies.