# How a Prophet 21 system fits together

> A conceptual map of a Prophet 21 installation, from the SQL Server database and middleware tier to the clients, background services and hosting.

Source: https://docs.lumina-erp.com/prophet-21/how-p21-fits-together/

**In short.** A Prophet 21 system is a SQL Server database, an application tier of Windows services, the clients people use and the edges (forms, files, mail, integrations). Place any problem on that map before you start fixing it.

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](/prophet-21/reading-p21-data-with-sql/).

## 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 |

:::tip[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.

:::note[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](/prophet-21/custom-crystal-forms/).

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?](/prophet-21/choosing-dynachange-or-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 |

:::caution[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.

## Sources

- [Prophet 21 Technology (Epicor)](https://www.epicor.com/en-us/products/enterprise-resource-planning-erp/prophet-21/technology/)
- [Epicor Prophet 21 Overview Brochure (Epicor)](https://assets.epicor.com/m/63302c83c86cc1ae/original/Epicor-Prophet-21-Overview-Brochure.pdf)
- [Prophet 21 DynaChange Business Rule examples (Epicor on GitHub)](https://github.com/Epicor/Prophet21/blob/master/Extensibility/P21.Extensions/P21.Extensions.Examples/readme.md)
- [Epicor announces schedule of final on-premises feature releases (Epicor, 2026-01-06)](https://www.epicor.com/en-us/newsroom/news-releases/epicor-announces-schedule-of-final-on-premises-feature-releases/)

---

Epicor, Prophet 21, P21 and DynaChange are trademarks or registered trademarks of Epicor Software Corporation registered in the United States and other countries. Kinetic is a trademark of Epicor Software Corporation. Lumina ERP is an independent consultancy and is not affiliated with, sponsored by or endorsed by Epicor.