What breaks when upgrading Priority?

The short answerMostly your own changes to Priority's standard objects. An upgrade brings Priority's standard forms, tables and procedures up to the new version's definitions, so a standard trigger your team customized, a column you added or changed on a standard table, or code that relies on something Priority changed is where things break. Objects that are entirely your own usually carry over as they are, but they can still fail when a standard object they depend on changes underneath them.

Customized standard triggers

Priority's forms run triggers on events such as checking a field or inserting, updating and deleting a record. When your team edited one of Priority's own standard triggers, the upgrade brings in the new version's text for that trigger, and your change won't be in it as-is. If Priority also changed the same trigger in the new version, the two have to be merged by hand — that collision is usually the most time-consuming item on the list.

Triggers your team added under its own names aren't replaced by the upgrade, but they run alongside Priority's code and can still be affected by what changed around them.

Table and column changes

A column that exists in your system but not in the target version, a column whose type changes, or a column that becomes narrower are the changes most likely to break data, reports and interfaces: a narrower column can truncate values that fit today. A column that becomes wider is usually safe, and a column the new version adds is informational.

Collisions: when you and Priority changed the same thing

The hardest cases are objects that both your team and Priority changed. Your version and the new version each contain changes the other doesn't, so neither copy can simply win. These need a developer to merge the logic and test the result.

Shared code: #INCLUDE and helper triggers

Priority trigger code can pull in shared code with an #INCLUDE line, and a form often carries helper triggers that only run when another trigger includes them. A change in one shared piece can affect every trigger that uses it, so a small change in one place can reach further than it looks.

Procedures, SQLI programs, reports and interfaces

Procedures and SQLI programs that read or write changed tables and columns, and the reports or interfaces that depend on them, can stop returning what you expect even when their own text hasn't changed. Treat anything that touches a changed object as something to test.

What a metadata check can't see

Comparing definitions finds structural risk: what changed, and where it meets your customization. It can't see your data, business rules that live in how people use the system, or external systems that integrate with Priority. Those still need a test plan and a test environment.

How to find out before you upgrade

1. Compare with a clean reference of your current version. Whatever differs from a clean copy of the version you run today is yours: customizations, additions, and any fixes you installed.
2. Compare with the target version, and every version in between. An upgrade installs each version on the way, not just the last one.
3. Recognize installed fixes. An object that matches a newer version's text is Priority's own code, not a customization.
4. Grade by risk. Start with the items where your change and Priority's change meet.

UpgradeGuard automates this comparison: a small read-only agent reads your environment's metadata, compares it with clean reference versions, and grades every difference as Critical, Medium, Low or Info, with the exact reason. The comparison is deterministic code; AI only writes the short summary at the top of the report.

Last updated 19 October 2026.