When EspoCRM dynamic logic for conditional fields is enough
Dynamic logic is the right tool when a sales or service form is cluttered with fields that only apply in some cases, or when it lets users pick combinations that make no business sense. It controls how a record form behaves as the user fills it in: it can show or hide a field, make it required, lock it, and filter the options offered in a dependent enum field based on other values already on the record. A sales team that only needs a contract end date for certain deal types, or a service team that should not pick a sub-category that belongs to a different product line, can usually solve the problem here without writing any code. Start by listing the forms that users complain about and noting which problems come from fields appearing when they should not, fields missing when they are needed, or options that should never have been offered. Those three symptoms map directly to the behaviors dynamic logic provides.
The key distinction is that dynamic logic shapes the form in the user interface. It does not decide whether a saved record is correct. A user who reaches a field through the API, an import, or a workflow can still write data that the form would have refused, so the rule is only as strong as the path it guards. If a requirement must hold for every record regardless of how it was created, plan it as data validation or server-side logic instead. Before you commit to a set of conditions, confirm in your own instance which entities, layouts and field types support each behavior, because support can vary by field type and version and the EspoCRM documentation is the place to check what the formula language can express.
The main boundary is with Formula scripts. Once a rule needs to calculate a value, copy data between records, or check several fields together before a save is accepted, dynamic logic alone is usually not enough and the work moves to before-save scripts configured in the Entity Manager. Decide early which side of that line each requirement falls on, because it determines who maintains the rule later and how it behaves during upgrades and imports. Write down each condition, whether it changes the form or the stored data, and who will own it. Requirements that mix both kinds are where teams most often end up with duplicated logic on the form and on the server, so agree on one place for each rule before building anything.
Which dynamic logic pattern fits each requirement
Hiding a field is the most common requirement and the easiest one to handle with interface behavior. A service team that sees the contract section only for enterprise accounts, or a sales team that sees a discount reason only when a discount is entered, gets a shorter form. Hiding is a presentation choice. The field still exists, still stores data and can still be read through the API, imports and reports unless role permissions also restrict it.
- Interface-only trade-off: Dynamic logic runs in the browser to change what users see. It does not stop an API call or a CSV import from writing the value.
- Field permissions for sensitive data: If a hidden value must not be visible to a role, combine the hide with role field permissions. Layout behavior alone is not a control.
- Stable conditions: Base conditions on fields that users fill in or that a before-save script sets, so the condition behaves predictably.
- Layouts vary: Detail, edit and side panel layouts may each need their own logic. Confirm the field behaves consistently in each.
- Formula takes over for dependent values: If a hidden field must be cleared or defaulted when its trigger changes, a before-save formula script is the place to enforce that.
Check whether hidden fields still appear in reports, exports or API responses, and confirm that role permissions match the intent of each hide.
A field that is required only in some cases, such as a loss reason on a lost opportunity or a tax identifier for corporate customers, is a common requirement. Dynamic logic can mark the field as required in the form, so users see the marker and cannot save without a value. This gives fast feedback, but the requirement is enforced only where the form runs.
- Form-level enforcement: The browser blocks saving through the interface. Records created through the API, imports, workflows or mass updates can still skip the requirement.
- Server-side check for regulated data: Where a missing value creates compliance or billing risk, add a before-save formula script that rejects the save or sets a default. Confirm which save paths run that script in the formula documentation.
- Import behavior: CSV import can create or update records in bulk. Test whether conditional requirements are evaluated during import, and plan a validation report if they are not.
- Trigger changes: If the trigger field can change after the required field is filled, decide whether the requirement applies again to existing records.
- Historical records: Older records may violate the new rule. Decide whether to backfill them, exempt them by date or leave them unchanged.
Confirm each save path (interface, API, import, workflow) and record which ones enforce the rule.
Locking fields after a deal is won or a case is closed protects prices, contract dates and audit trails. A read-only condition keeps the value visible while blocking edits in the form. Teams usually need an exception path, such as a manager correcting an error, so the lock design should name who can unlock a field and how that change is requested.
- Interface lock first: Read-only logic prevents accidental edits by standard users. It does not stop administrators, API users or imports.
- Server-side rules for binding values: For amounts or dates that must not change after approval, a before-save formula script can reject or revert changes. Confirm the exact behavior in the formula documentation before relying on it.
- Named correction role: Give a specific role permission to edit locked fields, and document the request and approval steps.
- Change history: Confirm that the record history captures changes made after the lock, so reviewers can see what changed and who changed it.
- Order of operations: If a workflow updates the status automatically, check whether the lock condition applies before or after that update.
Test the lock with a standard user, an API user and an import, and record the result for each.
Dependent enum options, such as a product category that limits the available product types or a country that limits region values, stop users from picking invalid combinations. Dynamic logic can change which options appear in a dropdown based on another field. This controls data entry in the interface, but it does not guarantee that every stored combination is valid.
- Usability control: Filtered dropdowns reduce wrong picks in the interface. Existing values outside the new list may remain stored.
- Clean up before tightening: Export current values before changing lists, and decide how to map or retire values that no longer fit.
- Validate the pair on save: Where a combination must be valid, a before-save formula script can check the dependent value and reject or correct it.
- Ownership of lists: Option lists change over time. Assign an owner for each list and a process for adding values.
- Imports and connected systems: Confirm how imported values outside the filtered list are handled, and whether connected systems send values that match the list.
Ask for a list of every dependent pair, the owner of each list, and the save paths that validate each pair.
Where dynamic logic ends and formula scripts begin
Dynamic logic handles what a form shows, requires and allows while a user edits a record. Formula scripts and workflows take over when a rule must run on save, through the API, or after a record changes. Mapping each business rule to one of these mechanisms early keeps the form behavior predictable and the server-side checks complete.
Field visibility and requirements
Showing, hiding, requiring or locking a field based on another field value is a form concern, so dynamic logic is the right fit. It only runs in the user interface, which means a record created through the API or CSV import can bypass it. Check which fields must stay enforced for every write path, and test the same rule through the API before relying on the form alone.
Dependent enum options
Narrowing the options of one dropdown based on a value chosen in another field keeps users from picking impossible combinations. This is form-level behavior and belongs in dynamic logic. Confirm how options behave on existing records whose stored value falls outside the new list, since that case is easy to miss during testing.
Calculated values on save
When a total, due date or score must be derived from other fields and stored, a Formula before-save script configured in the Entity Manager is the better fit. It runs whenever the record is saved, so the stored value stays correct regardless of how the record was edited. Review the script with the people who own the calculation, because a stored result is only as good as its formula.
Cross-entity and API-written checks
Rules that compare a record with related records, or that must hold for records written through the REST API, belong in an API before-save script or a Formula script rather than in form logic. Formula scripts are documented for Entity Manager before-save scripts and API before-save scripts, so both paths can enforce the same check. Confirm which integrations create or update records, because each one needs the rule.
Workflow-driven changes
When a change should happen after a status moves, a deadline passes or an approval completes, a workflow or BPM process is the better fit than dynamic logic. Workflows are part of the Advanced Pack, so confirm the extension is licensed for the deployment before designing around it. Keep the trigger, the action and the audit trail in the same workflow so administrators can trace why a record changed.
How to set up conditional fields in a test instance first
This sequence moves a conditional field change from business rule to production layout through a non-production instance, so each show, require and lock rule is confirmed for every role and team before users see it.
Map business rules with the sales or service owner
Sit with the owner of the sales or service process and write each rule as a plain sentence: which field depends on which value, which fields must be filled at each stage, and which records must be locked once a condition is met. Include the teams and portal users who touch the form, because the same rule often behaves differently for them. The step is done when the owner signs off a single rules list that names every trigger value. Check it by reading the list back aloud and confirming no rule relies on a value nobody has agreed on.
Inventory every field and its condition
Export the current layouts and entity definitions for the affected entities, then build a sheet with one row per field, listing its type, the rule that controls it, the action (show, hide, require, lock or filter enum options) and the layouts it appears on. Mark fields that feed formulas, workflows or hooks, since hiding them in the UI does not stop server-side logic from reading them. The step is done when every rule from the first step maps to at least one field row. Check the sheet for fields with no owner or with two rules pulling in opposite directions.
Configure the rules on a non-production instance
Apply the dynamic logic settings in the Entity Manager and layout editor of a non-production instance that mirrors the production entities, fields, teams and roles. Keep the changes small and grouped by entity so a failing rule is easy to isolate. Record each change in your change log with the field name, rule and layout. The step is done when the test instance loads each edited form without errors. Check the browser console and server logs during the first load, since a broken condition can fail silently on the page.
Confirm hidden fields keep their values
Create a record, fill every field including those that will be hidden, then change the controlling field so the dependent fields disappear and save. Reopen the record and confirm the hidden values are still stored, and that any formula or workflow reading them still sees the expected data. Repeat for a field that becomes locked. The step is done when the saved values match what was entered for every hidden and locked field. If a value is lost, treat the rule as a blocker and do not promote it.
Test required rules on create and edit
Run each required condition twice: once on a new record and once on an existing record that was saved before the rule existed. Try to save with the dependent field empty, then with a valid value, and note whether the form blocks the save with a clear message. Also test a path where the condition is not met, so the field is not required. The step is done when every required rule fires on both create and edit and no optional path is blocked. Check that legacy records do not fail to save when they are edited for an unrelated reason.
Test each path with users in every role and team
Create or reuse one test user per role and team that uses the form, then walk through each rule path as that user. Confirm that a user who cannot see a field also cannot set it through the UI, and that portal users see the same conditional behavior as internal users where they share a layout. Record the result for each user and path in a matrix. The step is done when every path passes for every role and team in the matrix. Check any gap by comparing the layout assigned to that team against the layout the rule was written for.
Promote the layout change to production
Repeat the verified configuration on production in the same order it was tested, using the change log as the checklist. Load one representative record per entity after the change and confirm the conditional behavior matches the test results. Keep a copy of the previous configuration so the change can be reversed if a user reports a problem. The step is done when the business owner confirms the production form behaves as the approved rules list describes. Note in your change record which rules were promoted and which were deferred.
Security and data integrity risks of form-only rules
Dynamic logic in EspoCRM controls what users see and type in the interface, but it does not by itself control what the API, imports, other layouts or other roles can write or read. The cards below cover the gaps teams most often miss, and each one points to a check you can run before go-live.
Hidden fields still accept API writes
A field hidden or made read-only by dynamic logic in a layout is still a field on the entity. Any API user whose role allows editing that entity can set it directly, and the form condition never runs for that request. Check each rule that protects a value against the API user roles, and confirm which validation runs for API requests in the EspoCRM docs before relying on a form condition for control.
Locked fields change through import
A field that is locked in the edit form can still change when records are imported. CSV import can run in Create and Update or Update Only mode and maps any column to a field, so a locked status or owner value may be overwritten in bulk. Restrict who can import, review the field mapping for every import, and test an update import against a locked field in a copy of the instance.
Role layouts expose data elsewhere
Hiding a field in one role's detail layout does not hide it in list views, search filters, side panels, exports or related-record panels that another role can open. A sales user may see a value that a service layout suppresses, or read it through a linked record. Compare each role's list, detail, search and panel layouts for every sensitive field and confirm the access rules with the roles documentation.
Permission overlap with ACL
Dynamic logic and ACL are separate mechanisms. When a user holds roles from more than one team or role, the effective permissions are the combination of all of them, which can grant edit rights that a form rule was meant to block. Map effective permissions per user type before assuming a rule restricts anything, and review teams that carry broad scope on sensitive entities.
Change tracking gaps
When a rule changes a value automatically, such as clearing a dependent field or setting a status, the audit trail must show who or what made the change. Confirm which changes are recorded in the stream and whether automated updates from formula, workflow or API calls appear there. Without this, a reviewer cannot tell a user edit from a rule-driven change during an investigation.
Testing across roles
Form rules are usually tested by the administrator who wrote them, and administrators often see fields that other roles cannot. Test each rule as every role and user type that touches the entity, including API users, and record the result. Repeat the test after any role, team or layout change, because a passing test under one role does not show the others behave the same way.
Questions teams ask before configuring EspoCRM conditional fields
Can an internal admin set up EspoCRM conditional fields without outside help?
Yes, for simple rules, a capable internal administrator can usually do this alone. Show, hide, require and lock rules are configured in the Entity Manager and layout settings without writing code, so a single field that appears when a stage changes is a reasonable first project. The work becomes harder when rules depend on several entities, when dependent dropdown options must stay synchronized, or when validity rules need testing across roles and teams. Ask your admin to walk through one real form end to end in a test instance before deciding whether to keep it in-house or bring in a partner for the larger rule set.
What drives the effort of conditional field work in EspoCRM?
Effort scales mainly with the number of rules, the number of entities they touch and how many layouts and roles see each form. Each additional condition multiplies the combinations that need testing, especially where one field controls several others. Other drivers include the number of teams or portals with different layouts, whether dependent enum options must be maintained as data changes, and how much existing data needs to be reviewed when a rule starts requiring a value. Ask any quote to list the rules individually, the entities involved and the roles to be tested, so the scope is measurable rather than a general estimate.
What do we need from the business owner before rules are configured?
The business owner must define the rules in plain language before anyone touches the configuration. That means which field triggers which behavior, which values are allowed in each state, who is allowed to override a locked field and what should happen to records that already violate a new rule. Without these decisions, the configuration tends to be rebuilt several times. Ask for a written rule table with one row per condition, the expected result, the owner who approves it and examples of records that should pass and fail. Your sales or service leads will often find gaps in this table that engineers would not notice.
Do conditional fields enforce data rules on API saves?
Not reliably on their own. Dynamic logic shapes what users see and must complete in the user interface, so it should not be treated as the only control on data entered through the REST API. For rules that must hold for every save, plan server-side enforcement, such as a before-save formula script or a hook, and test it with API requests as well as through forms. Confirm the exact behavior for your EspoCRM version in the official documentation and test it with an API user that has the permissions your integrations will actually use.
When should a conditional rule move to a formula instead?
Move a rule to formula when the value must be calculated or enforced on save, not just displayed or required on a form. Typical cases include deriving a field from other fields, blocking a state change that depends on related records, or applying the same logic to imports and API writes. Formula Script runs in before-save scripts configured in the Entity Manager, API before-save scripts, workflows and BPM, so the choice depends on where the data enters the system. Keep simple visibility and requirement rules as dynamic logic, because they are easier for administrators to read and change.
What should we confirm about our EspoCRM version before starting?
Confirm the exact version you run and whether a planned upgrade will change dynamic logic or formula behavior. EspoCRM publishes releases on its GitHub releases page, and the major versions differ in features and server requirements, so the version in production should be checked against the official documentation before rules are written. Also confirm the supported PHP and database versions in the server configuration docs, since an upgrade may require environment changes. If a major upgrade is planned, ask for conditional rules to be retested on the target version as part of the same scope.
Does DeployOpen certify that conditional rules meet a compliance standard?
No. DeployOpen configures and documents the rules, the test evidence and the access controls that support your compliance work, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Where a rule supports a control, such as a required field for a regulated record, ask for the rule to be documented with its owner, test cases and change history so your assessor can review it.
What to confirm in your EspoCRM version before you commit
Dynamic logic behaves differently across versions, form factors and customization layers, so the checks below belong in a test instance before any layout is signed off. Each item maps to a place where a rule that works on a desktop record can fail in production.
Supported operators and field types
Confirm which condition operators (equals, contains, empty checks, comparisons) and which field types can drive a show, require or read-only rule in the version you run. Some operators work on enum and boolean fields but not on multi-enum, link or date fields. Build one test rule per field type you plan to use and record what the form actually does, rather than relying on a general statement in the docs.
Mobile and portal behavior
Test every conditional layout on a phone-width browser and inside a portal user session, since portal roles and layouts can differ from internal ones. Check that hidden fields stay hidden, required fields still block save, and locked fields do not reappear after a screen rotation or a reload. Portal users are the most likely group to hit a rule they cannot see the source of, so include one in every test pass.
Interaction with Entity Manager fields
Confirm that custom fields created in the Entity Manager appear as valid sources and targets in dynamic logic, and that changing a field type or deleting a field does not silently break a rule that depends on it. Note which rules reference enum options, since renaming an option can change what a dependent list shows. Keep a list of every rule per entity so a field change triggers a review of the dependent rules.
Behavior on large layouts
Test rule evaluation on the most crowded detail and edit layouts you plan to use, with the number of conditional fields you expect at peak. Watch the time it takes for a dependent field to update after a change, and check whether slow updates appear on older browsers or low-powered workstations. If a layout slows noticeably, split it into tabs or move calculated values into a formula script.
Upgrade impact on custom layouts
Before any move to EspoCRM 10.0 or later, export the layout definitions and dynamic logic from your test instance, run the upgrade there and compare the rendered forms field by field. Pay attention to the rules that depend on core fields, since core field behavior can change between releases. Treat the upgrade as incomplete until every conditional form has been retested with real user roles.
How conditional fields hold up through EspoCRM upgrades
Conditional layouts and field logic need regression testing after every EspoCRM upgrade, because a release can change how layouts, dependent options and client-side behavior render, even when your own code and settings have not changed. EspoCRM 10.0.0 was released on July 2, 2026, and the 10.0.x line has continued since then, so any instance that moves from 9.x or from an earlier 10.0 patch should treat its conditions as unverified until a tester has checked them. The release notes on the espocrm/espocrm releases page are the starting point for identifying changes that touch forms, but they will not list every condition you rely on. Confirm with your partner or the vendor how the upgrade path for your installed version works, since UI-driven upgrades are disabled by default as of version 10.0.
Keep a written rule inventory for every condition in the instance. For each rule, record the entity, the field or layout it affects, the trigger field, the expected show, hide, require, lock or option behavior, the roles or teams it applies to, and whether a formula or only dynamic logic enforces it. Testers can then work through the list in a staging copy after each upgrade, using test records that cover both sides of every condition, including empty values and values at the boundaries. Store the inventory with the customization code so it is versioned alongside the layouts it describes. An illustrative example: a rule that makes a discount-approval field required above a set amount should be listed with the amount field as trigger, the approver role that can still edit it, and the record type it applies to, so a tester can confirm each part after the upgrade.
Plan the test effort before you schedule the upgrade, since the size of the inventory drives how long regression takes. Ask any partner quoting the work to state how many rules are covered, which environments the tests run in, who signs off each rule, and whether retesting after a later patch release is included or billed separately. Rules that depend on formula scripts should be tested at the same time as the dynamic logic they interact with, because a change in either can alter what a user sees. Record test results against the inventory version and date so the next upgrade starts from a known baseline.
How DeployOpen works on this
DeployOpen plans, implements, tests, documents and supports EspoCRM inside your own infrastructure, so conditional field rules are designed from your sales and service process first. Each engagement is agreed in writing before work starts, with scope, deliverables and timelines set out in advance.
How we scope
- Inventory every form where fields should appear, lock or become required based on record data
- Map each condition to a status, type, team or user role used by your teams
- Decide which rules belong in dynamic logic and which need a formula or hook
- Record the scope, deliverables and timeline in writing before build starts
How we build
- Configure visibility, requirement and read-only rules in the layouts for each entity and team
- Set up dependent enum options so each category only offers relevant choices
- Add invalidity rules and pair them with server-side checks so API writes follow the same logic
- Test each rule across create, edit and import paths using named test records
How we hand over
- Document each rule, the fields it affects, the condition used and the owner who approves changes
- Keep changes in a versioned extension or configuration export where the platform supports it
- Walk administrators through testing a rule before enabling it for end users
- Confirm the upgrade path and retest dynamic logic before each EspoCRM version change
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainers can cover adding new conditions as sales and service processes change
- Ask for a quote that separates one-time build work from recurring support hours
- Confirm response expectations and change handling in the written retainer agreement
