# How to use DynaChange in Prophet 21 to change screens without custom code > Source: https://netray.co/erp-help/p21-dynachange-rules-how-to-customize-screens > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System epicor ## Erp Epicor Prophet 21 ## Module DynaChange / Business Rules ## Query How to use DynaChange in Prophet 21 to hide fields or make a field required ## Alternate Queries - P21 dynachange rule examples - Prophet 21 make field required order entry - P21 hide field for a role - Prophet 21 business rules vs dynachange ## 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. ## Steps ### Make a field required for one role **Items:** - Do 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. - Create 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'. - Select 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. - Set 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. - Scope the rule. Apply it to a role or user group, not to everyone, unless the change is truly company-wide. - Save, 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. - Write 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. ## Sections ### What DynaChange can and cannot do **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Is DynaChange the same as business rules in Prophet 21? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms dynachange prophet 21, p21 dynachange rules, prophet 21 make field required, p21 hide field, prophet 21 customize screens, p21 business rules, dynachange role based, p21 order entry customization, epicor p21 customization no code --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json