How a Prophet 21 system fits together

Most Prophet 21 problems are easier to reason about once you can picture where each piece runs. A slow screen, a form that will not print, an import that stopped overnight and an API call that times out all live in different places. What follows is the map we sketch on a whiteboard at the start of an engagement.

The map stays conceptual, because server names, versions and sizing vary by installation. Your own environment is the source of truth.

The four layers at a glance

The table lists each layer, what it runs on and what it holds.

Layer	What it is	What lives there
Database	Microsoft SQL Server	Master records, transactions, settings and much of the customization metadata
Application tier	Windows servers running P21 services	The middleware that serves the web client and APIs, plus background services
Clients	Browser, and in some installs a Windows desktop client	The screens users work in
Edges	Report runtime, file shares, mail, integrations	Printed forms, import folders, email, connected systems

The database is the system of record. Everything else is a way of reading or changing it under the rules of the application. So the same bad data looks wrong on screen, on a report and through the API at once, and a fix made directly in SQL can bypass rules the application would have enforced.

SQL Server holds the system of record

Prophet 21 runs on Microsoft SQL Server. One database holds the data of a live company, in a conventional relational schema: order headers and lines, item master and item-location records, customers, suppliers, pricing, accounting and a long tail of supporting tables. Many table names are readable once you learn the abbreviations (oe_hdr for order entry header, inv_mast for the item master, inv_loc for item quantities at a location).

A few properties of the database matter day to day:

• Many records are logically deleted. A flag marks them deleted and they stay in the table. Any query or report that forgets this counts ghosts.
• Most records are scoped to a company. Multi-company installs share tables, so joins and filters need the company key as well as the record key.
• Customization metadata lives here too. Screen designs, business rule registrations and many settings are stored as rows, so a database restore to a test system brings most customizations along. Confirm what your version keeps outside the database before relying on that.

Because everything lands in one database, SQL Server health is P21 health. Index maintenance, statistics, backups and blocking all show up to users as "P21 is slow." We cover safe reading in Reading Prophet 21 data with SQL, safely.

The application tier of middleware and background services

Between users and the database sits a set of Windows servers running Prophet 21 components. The one you will hear about most is the middleware tier, which sits alongside the web application and the APIs, commonly on IIS.

Installs with many concurrent users or heavy integration traffic may run more than one middleware server behind a load balancer. Many also dedicate a server to background work so that scheduled jobs do not compete with people entering orders.

Alongside the middleware run background services. The exact list depends on version and licensed modules, but the categories are consistent:

Service category	What it does
Scheduled imports	Watch folders for files in a defined layout and load them
Job scheduling	Run recurring tasks such as pricing updates, reports and batch processes
Communication	Email or fax documents
Integration listeners	Serve connected products and add-ons

When nothing happened overnight

Look at the background services first. A service that stopped, lost access to a file share or is running under an account whose password changed will fail with no sign on screen, while the screens keep working.

Web and desktop clients

Users reach Prophet 21 through one of two styles of client. The web client runs in a browser and is served by the application tier. There is nothing to install per workstation beyond a supported browser, which makes it the natural fit for remote users and for hosted systems.

The desktop client is an installed Windows application. It was the traditional way to run P21 and is still present in many installs.

From an administrator's point of view, the important difference is where the work happens. In the web client, screen logic runs through the middleware, so middleware capacity and health directly affect how the screens feel.

Planning an upgrade with the desktop client

If your team still relies on the desktop client, confirm with Epicor which clients your target version supports before planning an upgrade, and check that any screen customizations you depend on behave the same way in the web client.

Reports and forms, right on screen and wrong on paper

Printed and emailed documents, known as transactional forms (invoices, pick tickets, packing lists, purchase orders, statements), are Crystal Reports designs in most installs. Prophet 21 hands the report the transaction data, and the report handles layout and formatting.

That split explains a whole class of issues where the data is right on screen and wrong on paper. In those cases the problem is in the report, and the transaction is fine. We cover the customization pattern in Custom transactional forms with Crystal Reports.

Operational reports come from a mix of built-in reports, Crystal, SQL Server Reporting Services in some shops and direct queries into a reporting tool.

Where customization lives

Prophet 21 gives you several layers to change behavior without changing the code Epicor ships:

Layer	Use it for
DynaChange Designer	How a screen looks and which fields are shown, required or defaulted
DynaChange Business Rules	Compiled .NET logic that runs on events in a window
Custom forms and reports	Anything printed or exported
Integrations	Logic that belongs outside the ERP

For how to choose among them, see DynaChange Rules, Designer, a report or an integration?.

Production and a play copy

A healthy install has at least two environments, production and a non-production copy, often called a play or test system. The copy is where you rehearse imports, train users and test rules and form changes.

It is only useful if it is refreshed from production often enough to resemble it, and if everyone can tell at a glance which one they are in. A test system with a production-looking login screen is how test orders reach real customers.

On-premises versus hosted

Prophet 21 can run on servers you own or be hosted, including by Epicor. In January 2026 Epicor announced a schedule of final on-premises feature releases, so anyone planning a long on-premises future should read that announcement (linked below) and confirm the dates with Epicor.

Conceptually the layers are identical. What changes is who can reach which layer:

Question	On-premises	Hosted
Who patches servers and SQL Server?	You	Usually the host
Can you query the database directly?	Yes, with your own logins	Depends on the hosting agreement
Where do import files and forms live?	Your file shares	Host-managed storage, reached by an agreed method
How do integrations connect?	Any method your network allows	Typically APIs or file drops the host supports

Get the hosted access model in writing

Before designing reporting or integration on a hosted system, get the access model in writing. Assuming direct SQL access that you do not have is the most common way a hosted integration plan falls apart.

Using the map to place a problem

When something breaks, place it on the map first:

Symptom	Where to look
Wrong on screen and in SQL	The data is wrong. Look at what wrote it
Right on screen, wrong on paper	The form or report
Screens fine, overnight work missing	A background service or its access to files and mail
Everything slow at once	SQL Server or the middleware tier
Only the integration failing	Authentication, the API tier or a change in the data the integration assumes

That first placement saves more time than any other step in diagnosis, because it rules out whole layers before anyone opens a log.