Get started
Why Logic Fabric
The idea behind Logic Fabric, Requirements-as-Code, and what it changes for Dataverse and Dynamics 365 projects.
Logic Fabric starts from one observation: on most business-application projects, the hardest part is not storing data but keeping the rules right, and keeping everyone’s understanding of those rules in step as they change. This page explains the approach Logic Fabric takes and why it matters for teams that build on Dataverse and Dynamics 365.
The gap in business-application projects
Section titled “The gap in business-application projects”A typical change to business logic passes through many hands. A business expert explains a rule, an analyst writes it into a specification, an architect designs it, a developer implements it as a plug-in or workflow, a tester writes tests for it, and someone deploys it. Each hand-off is a chance for the intent to be reinterpreted.
Over time the pieces drift apart:
- The specification ages. Documents are rarely updated as fast as the system changes, so they stop describing what the system actually does.
- The logic is hidden in code. Rules that live in plug-ins can be read only by developers, and knowledge leaves with the people who wrote them.
- Every change costs a full cycle. A small rule change still needs development, testing and a release.
- Platform tools stop short. Dataverse business rules are field-level; anything that spans tables, branches on many conditions or calls another system usually becomes custom code.
Requirements-as-Code
Section titled “Requirements-as-Code”Logic Fabric’s answer is Requirements-as-Code: the requirement is captured in a structured, typed form that is precise enough to run. The definition you review with the business is the same definition the platform executes.
Take a requirement such as “Gold customers ordering 100 units or more get a 20% discount.” In Logic Fabric it becomes a decision table with the columns Customer tier and Quantity and an output Discount %. A business reader can check the rows; the platform evaluates exactly those rows. There is no separate translation into code that could drift away from the table.
Because every rule is an artifact rather than free text or code:
- It is readable. Logic blocks, flows and processes are shown visually, with names, descriptions and documentation fields, in the terms your business uses.
- It is runnable and testable on the spot. Every logic block and logic flow has a Run dialog, so you check a rule against real inputs the moment you write it. Logic Assurance can generate and run test suites for you.
- It is documented from the source. The Logic Fabric CLI generates a documentation website from a project, so documentation describes what actually runs.
- It is versioned and portable. A project is exported as a package, kept under version control and promoted between environments with the same commands every time. See Deploy & ALM.
- It is analysable. Because definitions are structured, tools can trace dependencies, refuse to delete what is still in use and review designs for problems. Logic Guard and Logic Sentinel review quality and security for you.
One language for every product
Section titled “One language for every product”All Logic Fabric products share one type system and one expression language. You build expressions by picking values and functions in the expression editor, not by typing code: the editor checks types as you go and shows the result as a readable formula, such as Round(EstimatedRevenue * Probability / 100, 2).
The same expression works in a formula block, a flow step, a recipe condition, a process transition or an API precondition. Learn it once and you can design in every product.
What changes for your team
Section titled “What changes for your team”| Concern | Without a modelled approach | With Logic Fabric |
|---|---|---|
| Where rules live | Specifications, plug-in code and people’s heads | Named artifacts in a project, in your environment |
| Who can change a rule | Developers | Functional consultants, with the same review and release discipline |
| How a rule is checked | Separately written tests | The Run dialog while designing, plus generated test suites |
| How documentation stays current | Manual updates | Generated from the project |
| How changes move | Manual solution steps | Scripted export and import with per-environment mappings |
| What happens to complex processes | Linear business process flows or custom code | Stages, gateways, parallel branches and escalations |
What Logic Fabric is not
Section titled “What Logic Fabric is not”- Not a replacement for the Power Platform. Use Power Automate for its connectors, Power BI for analytics and Power Apps for the user experience. Logic Fabric adds the business-logic, process and API layer underneath. See Logic Fabric and the Microsoft ecosystem.
- Not a code generator. You never receive or maintain generated source code; you maintain the definitions.
- Not a way around Dataverse security. Logic is checked against the calling user, and preconditions let you restrict who can run each block, flow or process.
Our aim
Section titled “Our aim”Flowon builds Logic Fabric around a simple goal: building a business solution should be as natural as expressing the idea behind it. The people who understand a business problem should be able to state the rule precisely, see it run and change it safely, without losing quality, security or control.