DynaChange Rules, Designer, a report or an integration?

Every Prophet 21 shop accumulates change requests: "make this field required," "warn the rep when margin is low," "print the customer's part number on the pick ticket," "send new orders to the warehouse system." Each of those has a natural home, and putting it in the wrong one creates work that outlives the person who asked for it.

This guide is the triage we use. Our rule of thumb is to choose the lightest tool that fully solves the problem. Configuration beats a screen design, and a screen design beats code. Code inside P21 beats code outside it only when the logic belongs to the ERP.

The options at a glance

The table compares each option by what it changes, the skill it needs and its exposure to upgrades.

Option	What it changes	Skill needed	Upgrade exposure
Standard settings	How a built-in feature behaves	P21 administration	Low
DynaChange Designer	How a window looks: visibility, labels, order, required fields, defaults	P21 administration	Low to moderate
DynaChange Business Rules	Logic that runs on events in a window	.NET development plus P21 knowledge	Moderate
Report or form	What is printed, emailed or exported	Crystal or SQL reporting	Low to moderate
Integration	Data moving to or from another system	API or file integration development	Moderate to high

"Upgrade exposure" is the chance that an Epicor update changes something your customization depends on. None of these are zero, and all of them deserve a retest after an upgrade.

Check first whether it is already a setting

Before designing anything, check whether Prophet 21 already does it. P21 has a large number of system, company, location and customer-level settings. A surprising share of requests are "turn on the thing that exists."

A setting is supported, documented by the vendor and carried through upgrades. It always wins. Ask someone who knows the module. Search your own notes and the P21 user community. Only then move on.

DynaChange Designer when the screen is the problem

Use DynaChange Designer when the request is about what a user sees or must fill in:

• Hide fields a role never uses, to shorten the screen and reduce mistakes.
• Relabel a field to match your business vocabulary.
• Require a field before the record can be saved.
• Default a value for a particular role.
• Rearrange fields or tabs so the common path is faster.

Designs can be assigned to specific users or roles, which lets the warehouse, the counter and inside sales each see a version of the window that fits their job.

Designer is the right choice when the rule is static. "PO number is required for every order" is static. "PO number is required when the customer's terms say so" is not, and that is where rules come in.

Hiding is not security

A hidden field can still be changed through other windows, imports or the API. If a value must be protected, use permissions or a rule.

Designs are easy to create and easy to forget. Keep a spreadsheet listing each design, its purpose and who asked for it. It pays for itself at the first upgrade.

DynaChange Business Rules when you need logic

Business rules are compiled .NET code that Prophet 21 runs at defined points: when a field changes, when a window saves or when a user triggers the rule on demand. A rule can read the values on the window, look up related data, set values and stop an action with a message.

Good candidates:

• Conditional validation that blocks saving an order when a condition across several fields is true
• Derived defaults that set a field based on the customer, item or location
• Warnings that tell the user something important without blocking them, such as a margin below a threshold
• Small lookups that show related information at the moment it matters

Practices that keep rules out of trouble

Rules are where we see the most avoidable trouble. Adopt these practices from day one:

Practice	Why
Keep rules small and single-purpose	One rule per behavior is easier to test, disable and retire than one large rule that does six things
Fail safe	Decide what happens if the lookup inside the rule fails. A rule that throws an unhandled error can block order entry for everyone
Treat the database as read-mostly	If a rule must record something, prefer a narrow, well-understood write. Direct updates to core tables can bypass application logic
Version and document	Keep source in version control with a note on which window and event each rule is registered against
Test in play first, with realistic data	Rules interact with each other and with the logic of the window. Order of execution surprises are common

A report or form when the output is wrong

If the request is about what ends up on paper, in an email or in an export, the fix belongs in the report or form. Examples:

• Print a customer part number on the pick ticket.
• Show a different remit-to address for one company.
• Add a signature line to a delivery document.

Resist the temptation to add fields to a window or write a rule only so a value can be printed. If the value exists in the data, the form can almost always reach it. See Custom transactional forms with Crystal Reports for how to change forms without making upgrades painful.

Reporting requests that are analysis ("which customers are buying less this quarter") belong in a read-only reporting path outside the P21 screens. See Reading Prophet 21 data with SQL, safely.

An integration when another system is involved

If data must move between Prophet 21 and something else (an e-commerce site, a warehouse system, a carrier, a CRM, a supplier), you are building an integration, and the decision is about integration method. Our integration options guide covers that choice.

The trap to avoid is building integration logic inside a rule. A rule that calls an external web service on save ties your order entry speed to someone else's uptime. If the external call is slow, every save is slow.

If it is down, you have to decide whether orders can be saved at all. Almost always, the better design is to let P21 save normally and have an integration pick up the change afterward.

Walk the request through the decision questions

Take a request through these in order and stop at the first yes:

1. Does a standard setting do this? Use it.
2. Is it about visibility, labels, layout or a static required field? DynaChange Designer.
3. Is it about what is printed or exported? The report or form.
4. Does another system need to send or receive data? An integration.
5. Does it need conditional logic at the moment a user works in a window? A business rule.
6. None of the above? Revisit the request. It may be a process change rather than a system change.

Before you build anything

Whichever tool you choose, write down three things first: what the change does in one sentence, how you will know it still works after the next upgrade and who asked for it and why.