Count of new Party records created in Oracle Fusion’s Trading Community / Party model in the last 30 days, compared to the prior period. Tracks customer-base growth and onboarding volume.
At a glance
The number of new Party records, customers and accounts, created in the Oracle Fusion Trading Community Architecture (TCA) Party model in the last 30 days, compared against the prior 30-day window. This is the customer-master growth pulse: it tells you how fast new business entities are entering Oracle, whether onboarding is keeping pace with sales, and whether a sudden spike or dip in record creation hints at a data-load event or a pipeline stall. It counts the act of creating a master record, not revenue.
| What it counts | The count of Party records created in the Oracle Fusion TCA Party model within the period. Includes Organization and Person party types where configured. Counts the master entity, not the number of sites, contacts, or accounts attached to it. |
| Currency | n/a. This is a count metric, not monetary. |
| Business Unit scope | Parties in TCA are global, but the card respects the dashboard’s Business Unit filter via the customer-account assignments derived from each party. By default counts every new party the connected role can see. |
| Time window | 30D vsP (last 30 days versus the prior 30 days). |
| Alert trigger | None by default. A sharp spike usually indicates a bulk data load; a sharp dip usually indicates an onboarding stall. |
| Roles | owner, finance, marketing |
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US Fortune 500 B2B-plus-DTC distributor on Oracle ERP Cloud. The 30-day window covers 14 Mar 26 to 12 Apr 26, compared to the prior window 12 Feb 26 to 13 Mar 26.| Party type | This period | Prior period |
|---|---|---|
| Organization (B2B accounts) | 410 | 372 |
| Person (DTC / individual) | 1,260 | 1,190 |
| New Party Records (this card) | 1,670 | 1,562 |
- Up 6.9% versus the prior period. Steady, healthy customer-master growth. There is no spike that would suggest a bulk load and no collapse that would suggest an onboarding stall, so the number reflects organic acquisition flowing into Oracle.
- The card counts parties, not accounts or sites. A single new B2B Organization party may carry several customer accounts and many ship-to and bill-to sites underneath it. This card counts the party once. If you need the account-level figure, pair with Active Customers, which counts transacting accounts.
- B2B versus DTC split tells a story. 410 new organisations against 1,260 new persons is a typical hybrid mix. A swing toward Organization parties usually signals a wholesale or marketplace push; a swing toward Person parties signals DTC acquisition. Marketing reads this split alongside campaign timing.
- Watch for a sudden 10x spike. A jump from 1,670 to, say, 16,000 almost always means a data migration or a marketplace bulk import ran, not real acquisition. The card will move sharply and the ecom customers absent from Fusion party card usually drops in the same window as the backlog clears.
- A new party is not yet a customer. Creating the master record precedes the first Sales Order. Some of these 1,670 will transact this period; others are pre-loaded for a contract not yet active. To see who actually bought, use Active Customers.
Sibling cards merchants should reference together
New Party Records measures onboarding into the customer master. Pair it with these to connect record creation to real transacting behaviour and data hygiene.| Card | Why pair it with New Party Records |
|---|---|
| Active Customers | New parties are the top of the funnel; active customers are the ones who actually transacted. The gap is your activation rate. |
| Ecom Customers Absent from Fusion Party | The integrity counterpart. If commerce is acquiring customers faster than Oracle is creating parties, this card lags and that card grows. |
| Customers with TaxRegistrationNumber Mismatch (B2B) | Newly onboarded B2B parties are the most common source of tax-ID mismatches. |
| Customer Churn Signals | Growth on one side, attrition on the other; net customer-base movement needs both. |
| Top Customers by Revenue | Tells you whether new parties are diversifying the base or whether revenue stays concentrated in the same few accounts. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud:Navigator → Receivables → Billing → Manage Customers (filter on creation date, last 30 days) Navigator → Customer Data Management → Manage Parties (the TCA party master directly) Reports and Analytics → OTBI → Customer Real Time / Trading Community Real Time Subject Area (count distinct parties by creation date)Manage Parties in Customer Data Management is the canonical TCA view and the closest one-to-one with this card. Manage Customers in Receivables shows the account layer, which sits one level below the party, so its counts can be higher than this card when a single new party carries several accounts. OTBI on the Trading Community subject area lets you reproduce the exact count distinct of parties by creation date. Common mistakes when comparing against Oracle’s own reports:
- Counting accounts instead of parties. Manage Customers (Receivables) counts customer accounts; this card counts parties. One party can hold many accounts. Match the level before reconciling.
- Counting sites or contacts. A new party often arrives with multiple ship-to sites and contacts created on the same day. Those are not separate parties. A report keyed on sites will overstate dramatically.
- Ignoring party type filters. If your implementation creates internal or one-time parties for non-customer purposes, an unfiltered report counts them. The card counts the party types configured as customers.
| Reason | Direction | Why |
|---|---|---|
| Party vs account vs site level | Oracle report often higher | This card counts parties. Account- and site-level reports count more rows per new party. |
| Bulk data load timing | Either | A migration or marketplace import creates many parties on one date. The card and a creation-date report should agree, but a spike can be onboarding noise, not acquisition. |
| Party type inclusion | Either | Internal, one-time, or prospect parties may or may not be in scope. Align the type filter. |
| Sync timing | Small | Card refreshes on the Fusion REST API cadence; a party created in the last few minutes appears at the next sync. |
| Merge and de-duplication events | Card lower | TCA party merges collapse duplicates. If a merge runs in-period, the net new count can fall below the raw creation count. |