How to use DynaChange in Prophet 21 to change screens without custom code
How to use DynaChange in Prophet 21 to hide fields or make a field required
Also searched as
- P21 dynachange rule examples
- Prophet 21 make field required order entry
- P21 hide field for a role
- Prophet 21 business rules vs dynachange
Short answer
DynaChange is Prophet 21's built-in tool for adjusting windows without programming: you can hide or disable fields, change labels, make fields required, and set defaults, scoped to a user, role or the whole company. Build the change against the window you want to alter, test it in a test environment with a real user role, and document each rule so it survives upgrades.
Applies to: Prophet 21 releases that include DynaChange. Menu locations and the available rule options differ by version, so confirm in your release's help and with your Epicor consultant.
Make a field required for one role
- 1Do this in a test or play environment first. Open the window you want to change, for example Order Entry, and open DynaChange for that window from the tools or right-click options available in your release.
- 2Create a new rule set and give it a clear name that says what it does and who asked, for example 'OE - require customer PO for Dealer role'.
- 3Select the target field on the window. DynaChange identifies fields by their underlying names, so confirm you have the field you meant by checking its label and tab.
- 4Set the property you want to change, such as required, visible, enabled, label text, or default value. Change only one property per rule so you can turn it off cleanly later.
- 5Scope the rule. Apply it to a role or user group, not to everyone, unless the change is truly company-wide.
- 6Save, then log in as a test user with that role and try to break it: save with the field blank, tab through the window, test any related windows that use the same field.
- 7Write down the rule, the reason, the requester and the date in your change log. Promote to production in a quiet period and tell the affected users.
What DynaChange can and cannot do
DynaChange changes how a window presents and validates data. Typical uses: hiding fields a branch never uses so counter staff stop filling them in, making a customer PO number required for accounts that always need it, relabeling a field to match your terminology, and setting a default such as a ship-via or terms code.
It is not a place for business logic that involves calculations across records, calls to other systems, or workflow approvals. For that you are looking at other P21 tools: business rules where they apply, the Data Interchange and API capabilities for integration, custom reports, or a development project with Epicor or a partner.
Keep the principle simple: if a rule is about what a user sees or must enter on one screen, DynaChange is probably right. If it is about what the system does after save, or between windows and systems, it is not.
Role-based rules and testing
The most common mistake is scoping a rule to everyone. A field made required for all users breaks the import jobs, EDI processing, and eCommerce order feeds that create orders without that field. Scope to the human roles who need the behavior and test integrations separately.
Test with a user who actually holds the target role, not with an administrator account. Administrators often see everything and can mask rules or permission interactions. Check the window with the role's real security settings, because a field hidden by security and a field hidden by DynaChange behave differently.
Also test the screens that share the data. A field you made required on Order Entry may be updated from another window, a mobile app, or a scan gun transaction. Find those paths before go-live.
Governance: keeping rules from becoming a mess
After a few years, a company can accumulate dozens of DynaChange rules with no one remembering why. Treat them like code. Keep a register with the window, field, property, scope, reason, requester, and test notes. Review it when you plan an upgrade.
Use consistent naming. Include the window abbreviation, the action and the scope in the rule set name. Prefer many small rule sets over one giant one, so that disabling a single behavior does not remove others.
Before an upgrade, export or document your rules and re-test the key windows in the upgraded test environment. Window layouts can change between releases, and a rule bound to a field that moved or was renamed may stop applying or behave unexpectedly.
Common pitfalls
- !Making a field required for everyone and breaking EDI, eCommerce, or import-created orders that do not populate it.
- !Building and testing directly in production. A bad required-field rule on Order Entry stops the counter immediately.
- !Testing only as an administrator, which hides role and security interactions.
- !Stacking several property changes in one rule so you cannot disable one without losing the rest.
- !Not documenting rules, then losing them or misunderstanding them at upgrade time.
How an ERP-grounded AI assistant handles this
An assistant grounded in your Prophet 21 setup can help with the planning side: given a request like 'make PO number mandatory for contractor accounts', it can show how many recent orders for those customers lack one, which order sources (counter, EDI, web) create orders without it, and which rules already touch that window. That tells you whether the rule will break an integration before you build it. It reads data and drafts the rule description; the DynaChange change itself is made by your admin.
Frequently asked questions
Is DynaChange the same as business rules in Prophet 21?
They overlap in purpose but are different tools in the product. DynaChange focuses on adjusting the presentation and basic validation of windows. Business rules address broader rule-driven behavior. Which one fits depends on your release and what you need, so check with your Epicor consultant before choosing.
Will my DynaChange rules survive an upgrade?
They are stored as configuration, not code, so they generally carry forward, but window changes between releases can affect them. Document every rule and re-test key windows in the upgraded test environment before going live. Do not assume a rule still works because it still exists.
Can I apply a rule to only one branch or location?
Scoping is mainly by user or role, so the usual approach is to put branch staff into roles that reflect the behavior you want. If you need location-specific behavior beyond that, discuss options with Epicor or your partner rather than forcing it into rules.
Why does my required field not stop an EDI or web order?
Rules that apply on the window apply to users working in the window. Orders created by integrations go through other entry points and may not use the same validation. Handle those with validation in the integration or a post-import check.
Related
Epicor Application Studio: understanding customization layers
Kinetic UI is built in layers loaded in order - Base (Epicor-delivered), Customization (Application Studio, company/layer-wide), Personalization (user- or role-specific, applied on top), and optionally Extended (packaged add-on layers) - and a change you make will not appear if a higher layer overrides the same control or if you are testing in the wrong layer context.
How-toProphet 21 is slow or freezing: how to find and fix SQL Server blocking
When Prophet 21 hangs for many users at once, the cause is usually one SQL Server session blocking others, or a long-running report holding locks on hot tables such as order and inventory location rows. Find the head blocker with sys.dm_exec_requests, identify the statement and the P21 client or report behind it, and fix that, rather than restarting the application server.
Error fixProphet 21 API returns 401 Unauthorized: how to fix token and OData access
A 401 from the Prophet 21 API almost always means the bearer token was never obtained, has expired, or is not being sent on the call. Request a token from the security endpoint with a valid P21 user, send it in the Authorization header on every request, and make sure that user has access to the data and services you are calling.
Error fixFixing Epicor BusinessObjectException: BPM Directive Errors
A BusinessObjectException that says "A Business Process Management (BPM) directive has raised the following error" means a directive on that business object stopped the transaction, either deliberately via a Raise Exception widget or accidentally via an unhandled .NET error in Custom Code. Expand the InnerException on the error dialog to see the real message and the directive name, then open BPM Designer for that object and method to find the widget that fired.
How-toFixing a Slow Epicor BAQ (Business Activity Query)
A slow BAQ in Epicor is usually caused by unindexed join columns, a subquery or calculated field forcing a table scan, or the BAQ pulling far more rows than the dashboard actually displays before filtering client-side. Fix it by reading the SQL Server execution plan Epicor generates, moving filters into the BAQ criteria instead of the dashboard filter panel, and replacing subqueries with joins where possible.
How-toEpicor MRP Runs but Generates No Suggestions
When Epicor's MRP process completes without a job or purchase suggestion for a part you expect one for, the cause is almost always the part's own configuration (Part Class Type, Make Direct, Non-MRP flag, planning Time Fence) or the demand not being linked in a way MRP recognizes, not a defect in the MRP engine. Work through the part's Planning tab, its safety stock and lead time setup, and the demand source (sales order line status, job material requirement) before assuming the run itself failed.
AI for ERPAI for Epicor Prophet 21, Built for Distribution Operations
Prophet 21 AI for distributors: on-prem or private-cloud LLM grounded in P21 order, inventory, and purchasing data, for order follow-up, forecasting, and pricing questions.
Stuck on Epicor Prophet 21?
Talk to engineers who work inside Epicor Prophet 21 every week, and who build private AI that answers these questions from your own ERP data.