A KPI configuration is the named definition of a measure — which entity's records are meant to count, which field supplies the value, how the values are meant to aggregate and who is being measured. Incentive plans reference KPI configurations from their targets and from each member's target assignment, and the plan's target grids group by that reference. Separately, Performance KPI rows hold the per-document, per-period accruals that the incentive engine sums when it scores a target. Both record types are covered here, together with what each one does and does not drive today.
Where to find it
Open the Rewards app and choose KPI Configurations in the app navigation. The list view All KPI Configurations shows the name, KPI name, parent KPI configuration, active flag, the partner-account and resource field mappings, the trigger object and who created the row; New opens the create form. Opening a row shows a Details panel with the full definition and two related grids, All KPI Rules and KPI Data. The entity belongs only to the Rewards app; if your current app is a different one, the same screens open under that app's navigation bar.
Creating and editing a KPI configuration needs create/edit access to the KPI Configuration and KPI Rules entities in your security profile, and the Rewards module must be licensed for the tenant.
Read the KPI Configuration screens
- 1
KPI Configurations sits in the Rewards app navigation; if another app is current the same list opens under that app's bar.
- 2
The record count and view name (All KPI Configurations) tell you how many definitions are already available.
- 3
Name opens the saved definition — either the KPIC… document number or a name typed by the author.
- 4
KPI Configuration shows the parent in a hierarchy; a dash means the definition is standalone.
- 5
Resource Field Name and Trigger Object Name are typed field and entity names — stored as entered and not validated or evaluated by the engine.
- 6
New opens the create form described below.
The list is the registry of definitions a plan author can pick from. Check it before creating a new one: two configurations that differ only in name make plan evidence harder to explain, because targets and compensation lines carry the reference, not the description.
- 1
KPI Name is the display name plan authors will see; Is Active is mandatory and marks whether the definition is offered for use.
- 2
Trigger Object Name is the source entity typed as text (for example Order); the form does not check it against the data model.
- 3
Member Type (mandatory) says whom the KPI measures — Branch, Resource or Customer.
- 4
Date Field Name (mandatory) and the other Data Fields name the source-record fields that identify when a record counts and whom it belongs to.
- 5
Value Function and Reward Function record the intended aggregation; in the current release nothing executes them — the figures a plan scores come from Performance KPI rows.
- 6
Save stores the definition so incentive targets can reference it.
The create form is a single page of collapsible sections. Only Is Active, Member Type, Date Field Name and Include Child Resources are mandatory; everything else describes the measure and is stored as entered. Field names are typed as the source entity's field names (for example DocumentDate, SalesExecutiveId) — the form does not validate them against the entity named in Trigger Object Name.
- 1
The record heading is the KPIC… document number (or the typed name) that targets and compensation lines reference.
- 2
KPI Name and Is Active — the label plan authors see and whether the definition is offered for use.
- 3
Trigger Event, Trigger Object Name and Member Type record the intended source and whom the KPI measures; they are stored, not evaluated.
- 4
Data Fields name the source-record fields (DocumentDate, PartnerAccountId, BranchId, SalesExecutiveId, AccountId) — typed text that is not validated against the entity.
- 5
All KPI Rules holds optional field/operation/value restrictions; an empty grid is normal.
- 6
KPI Data stays at 0 — the incentive engine reads Performance KPI rows instead.
The saved record is the verification surface for a definition a plan references. The related grids are usually empty: KPI Rules only exist if someone added them, and KPI Data is written by nothing in the current release (see below), so an empty grid is not a sign that the configuration is broken.
The KPI Configuration record
The form groups the fields into these sections:
| Section | Fields | What they record |
|---|---|---|
| Information | KPI Name, Is Active | The display name plan authors see, and whether the definition is offered for use. The record's Name is the auto-generated document number (KPIC…) or a name you type in the list. |
| Trigger Configuration Details | Trigger Event, Trigger Object Name, Member Type | The source entity (typed, for example Order or ServiceOrder), the event meant to feed it (Scheduled, AFTER_INSERT, AFTER_UPDATE, AFTER_DELETE) and whom the KPI measures — Branch, Resource or Customer. |
| Calculation Fields (Decimal) | Value Field Name (two), Reward Field Name | Which numeric fields on the source record carry the measured value and an optional reward-side value. |
| Data Fields | Date Field Name, Item Field Name, Partner Account Field Name, Branch Field Name, Resource Field Name, Account Field Name | The source-record fields that identify when the record counts and which company, branch, resource, account and item it belongs to. |
| Filters | Include First N Records, Include Last N Records, Include Child Resources | Sampling limits and whether a resource's subordinates roll up into its figure. |
| Result Fields | Value Function, Reward Function, Formula Value Field Name, Formula Reward Field Name | The intended aggregation — Value Function offers Count, Average and Formula; Reward Function offers Sum — and the fields a formula result would be written to. |
| Rule Criteria | Rule Success Criteria, Rule Success Custom Logic | How the KPI rules combine. The default picklist only seeds Always (No Criteria); custom logic is free text such as (1 AND 2) OR 3. |
Fields that exist on the record but are not on the default form: Account Group, Partner Account Group and Item Group (scope lookups), Is Group and Parent KPI Configuration (the hierarchy the list's KPI Configuration column shows), Last Executed timestamp and Job Queue. Add them to the layout through the form layout designer if you use them.
KPI rules
A configuration can carry KPI Rule rows — each a field name, an operation (Not Equal, Greater Than or In), a value and a sequence number — meant to restrict which source records count. They are created from the All KPI Rules grid on the record.
What a KPI configuration drives today
Be precise about this when you explain a payout. In the current release the KPI configuration is a definition and grouping key, not an executed calculation:
- Incentive targets and incentive resource targets carry a KPI configuration reference. The plan's Targets by Resources and Targets by KPI tabs group and filter the target grid by exactly this reference, so a plan with several KPIs gets one set of member targets per KPI — see Incentive plans.
- Compensation lines and compensation slabs carry the reference too, so a paid line stays traceable to the KPI it was scored under.
- Nothing evaluates the definition. No server code reads Trigger Object Name, Trigger Event, the field-name mappings, the value or reward functions or the KPI rules; no process writes KPI Data or KPI Data Detail rows, and Last Executed is never stamped. The measured figures that actually decide a payout come from Performance KPI rows and the target's type, described next.
If a plan needs a measure the target types do not offer, the working route is a Custom KPI target (below), not a KPI configuration with a formula.
Performance KPI records
The incentive engine scores a target by summing Performance KPI rows keyed by plan, period and target, and by the performer — account, partner account, branch or resource — optionally broken down by item and SKU. The rows are written by the Performance KPI engine when a trading document goes through its KPI calculation action: sale orders, sale invoices, purchase orders, bills and opportunities feed it. Each document produces a parent row with document counts and header amounts, plus one item row per item a target selects. The measures a target can read:
| Measure family | Fields |
|---|---|
| Counts | Number of orders, invoices, bills, quotes, leads, opportunities, purchase orders, repair orders, service requests |
| Sale values | Total sale order amount, total sale invoice amount, total amount, total tax amount |
| Quantities | Total sale order quantity, total sale invoice quantity, total quantity |
| Purchase side | Total purchase order amount and quantity, total bill amount and quantity |
| Service side | Total repair order amount and quantity, total service request amount and quantity |
The target's Incentive Target Type picks the field: No Of Sale Orders, No Of Unique Invoices, No Of Unique Items, Sale Order Amount, Sale Amount (invoice amount), Sale Order Quantity, Purchase Order Amount, Purchase Order Quantity and Custom KPI, which reads the Performance KPI field named in the target's Custom KPI Field Name (the field's technical name, for example TotalBillAmount). The engine also recognises No Of Invoices and Invoice Quantity, but those two labels are not in the default picklist (it offers Sale Invoice Quantity instead, which the engine does not match). Any other target type — including the bill, finance, insurance, hours and repair-order types the picklist lists — contributes zero.
Common questions
What is the difference between KPI Data and Performance KPI?
KPI Data is the aggregated-result table designed for KPI configurations — one row per member and period with a per-document detail breakdown. In the current release nothing writes it, so the grid on a configuration stays empty. Performance KPI is the per-document accrual the incentive engine actually sums when it evaluates a target; if you need to explain an achieved figure, look at the Performance KPI rows for the plan and period, not at KPI Data.
How does a plan use a custom measure?
Set the target type to Custom KPI and enter the Performance KPI field to read in Custom KPI Field Name. The engine reads that field from every matching Performance KPI row, sums it into the achieved figure and stamps the result on the compensation line as the custom KPI value. Referencing a KPI configuration on the target does not change what is measured — it labels and groups the target.
Can one KPI configuration serve several plans?
Yes. The configuration is independent of any plan; targets and member assignments in any number of plans can reference it, and the plan grids group by it per plan.
Why is the KPI Configurations tab showing under a different app?
The current app is a per-user preference; the KPI Configuration screens open under whichever app you last used, even though the entity belongs to Rewards. Switch to the Rewards app from the app launcher if you want the Rewards navigation around it.