MDF Data Model

The Market Development Funds module stores its data in a set of related entities. This page describes what each one holds and how they connect, so you can query and extend the module correctly.

Resolve entity ids and key prefixes at runtime. Several MDF entities are provisioned per install, so their ids differ between portals. Query the metadata rather than hard-coding them.

The Entities

Entity	Holds
`MdfProgram`	The budget envelope: period, currency, total budget, funding model, and the activity types eligible within it.
`MdfAllocation`	One partner's budget within one program. The anchor for all balance calculations.
`MdfFundRequest`	An approval-tracked funding request from a partner.
`MdfActivity`	A marketing activity proposed for funding, belonging to a request.
`MdfClaim`	An expense claim against one approved activity.
`MdfReimbursement`	A payment record.
`MdfReimbursementClaim`	Junction between a reimbursement and a claim, carrying the amount applied - so one payment can settle several claims.
`MdfProofOfPerformance`	Evidence records. These hang off the Activity, not the Claim.
`MdfLedgerEntry`	Financial ledger entries against an allocation. The source of every balance.
`MdfActivityType`	An activity category and its proof-of-performance rules.
`MdfActivityTemplate`	A reusable pre-filled activity.
`MdfClaimFileReview`	A reviewer's decision on an individual claim attachment.
`MdfActivityAttribution`	A lead attributed to an activity.
`MdfClaimFeed`	Feed-aliased claim audit log. Attaches by polymorphic `ParentId`, not a typed claim reference.

Module configuration lives in MdfModuleSetting, which is a custom setting rather than an entity.

MdfRequest is not part of this module. It belongs to the earlier Marketing Development Fund module and is unrelated. Do not query it expecting this module's data.

How They Connect

Program
  └── Allocation (one per partner)
        └── LedgerEntry (every financial movement)

Program
  └── FundRequest (from a partner)
        └── Activity
              ├── ProofOfPerformance
              ├── ActivityAttribution (leads)
              └── Claim
                    ├── ClaimFileReview
                    └── ReimbursementClaim ── Reimbursement

Two relationships are worth noting because they are commonly assumed wrong:

Proof of performance belongs to the activity, not the claim. A single activity's evidence serves every claim filed against it.
Reimbursement to claim is many-to-many through the junction, so one payout can settle multiple claims and carry the amount applied to each.

Balances Are Derived

No balance is stored. Available is computed as the allocation's amount minus the net of its ledger entries, where that net already combines commitments, releases, payouts and adjustments. Do not sum committed and spent separately and subtract both - a payout appears in both, and you would double-charge every reimbursement.

Ledger entry types are Commitment, CommitmentRelease, Reimbursement and Adjustment. Each records the source that produced it: a request, an activity, a claim, a reimbursement, or a manual action.

A negative available balance is legitimate and is not clamped - it means the allocation is over-committed and should be surfaced, not hidden.

CRM-Agnostic Lookups

MDF does not assume which records represent accounts, contacts and leads, because that differs between standalone portals and CRM-connected ones. The lookup fields joining MDF records to your partner accounts and contacts are therefore created during module activation rather than shipped with it, once the target entities have been resolved.

This is why activation is a schema-changing operation, and why those fields do not exist on a portal where MDF has never been activated.

Access Control

Access is granted two ways, and they are independent: the Enable MDF Management Access permission on a role grants the whole module, while a program audience grants one program. Administrators always have full access. Reimbursement is administrator-only regardless of the Enable MDF Management Access permission.

Beyond that, the module requires both the MDF licence and the partner portal product to be present at all.

See More

MDF REST API
About Market Development Funds (Administrator documentation)

MDF REST API >>

Table of Contents