System Integrations
Marketing Central doesn't operate in isolation. It integrates with six external systems, each providing something the platform needs to function correctly. These are not optional bolt-ons — they are first-class architectural components, designed and built as part of the core platform.
Admin System (CRM)
Liberty Admin System
Internal SQL-based CRM: entity, territory, office, and association records
What It Provides
The authoritative source for the organizational hierarchy: which entities exist, which territories they own, which offices are active under each territory, and how office associations (primary owner, support associations) are structured. This data is the basis for all access scoping in Marketing Central.
Integration Approach
Real-time sync is the preferred approach — Marketing Central queries the Admin API for current data rather than relying on scheduled flat-file imports. This eliminates the lag that currently causes franchisees to see stale data. The exact API mechanism (REST, webhook, or hybrid) is confirmed during discovery. If real-time sync is not available for all data types, near-real-time (minutes, not daily) is the fallback.
Microsoft Dynamics GP
Microsoft Dynamics GP
Liberty's accounting and AP system — downstream of Marketing Central for fund activity
Outbound (MC to GP)
Approved claims are pushed from Marketing Central to GP for AP processing. Each approved claim record contains: franchisee entity ID, banking details (routing + account), claim amount (in correct currency), period, and Marketing Central claim reference ID. This push is triggered automatically when a reviewer approves a claim — no manual step, no file creation.
Inbound (GP to MC)
When GP confirms that an ACH payment has been issued for a claim, it sends a payment confirmation back to Marketing Central. This confirmation closes the claims loop — the claim is marked Paid, the fund ledger is updated to reflect the disbursement, and the franchisee is notified. GP also provides any payment failure notifications (insufficient account, routing error) for admin investigation.
Marketing Central owns the fund balance ledger. GP is the AP and accounting record. This means the available balance a franchisee sees at checkout is computed from Marketing Central's ledger, not derived from a GP balance query. GP receives results (approved claims for payment); it does not drive balance calculations. Reconciliation reports compare the two systems on a scheduled basis to ensure they remain in agreement.
FranConnect / LRC
FranConnect / Liberty Resource Center
Franchise intranet — SSO entry point and supplemental org data source
What It Provides
FranConnect hosts the Liberty Resource Center (LRC), the intranet where franchisees access all their business tools. Marketing Central will be accessible from a link in the LRC, providing a natural entry point that franchisees are already familiar with. FranConnect may also supplement the Admin System with certain office attribute data not available via the Admin API — confirmed during discovery.
Integration Approach
The LRC link to Marketing Central uses SSO via Entra External ID — franchisees who are already logged into the LRC do not need to authenticate again. Any supplemental FranConnect data (if needed) is fetched via FranConnect's API using a service account credential stored in Azure Key Vault. Bonfire has prior experience with the FranConnect API from existing Liberty integrations.
Vendor APIs
Print & Fulfillment Vendors
Impressions In Print, Awarity, Potato Head, Alwan Printing, 1 Vision, Entripy, and others
Outbound (MC to Vendor)
When a franchisee places an order for a vendor's product, Marketing Central transmits the order to the vendor's system: product SKU, quantity, customization file (generated PDF), shipping address, and required ship date. The transmission mechanism is per-vendor (REST API, SFTP, or email with structured attachment) determined during the vendor discovery phase. Per the RFP process, direct vendor contact has not yet occurred.
Inbound (Vendor to MC)
Vendors transmit order status updates back to Marketing Central as orders move through production and fulfillment. High-volume vendors with API capability integrate via webhook or polling; lower-volume vendors update status via the vendor portal interface. Tracking numbers, estimated delivery dates, and delivery confirmations flow through the same integration path.
Shipping Carriers
UPS, FedEx, USPS
Real-time carrier rate APIs for accurate shipping quotes at checkout
Rate APIs
UPS, FedEx, and USPS all provide public developer API programs for real-time rate queries. Marketing Central queries these APIs at checkout using the configured product dimensions and weight, the vendor's ship-from origin, and the franchisee's ship-to address. The response includes all available service levels (Ground, 2-Day, Overnight) with actual prices — not flat-rate estimates.
Tracking APIs
Carrier tracking APIs allow Marketing Central to poll for delivery confirmation on shipped orders, automatically updating order status when the carrier confirms delivery. Franchisees see delivery status in their order history without checking the carrier website. Tracking credentials are stored in Azure Key Vault; polling is rate-limited to respect carrier API policies.
Payment Processor
Payment Processor (TBD)
Credit card authorization and capture at checkout — processor not yet selected
Architecture (Processor-Agnostic)
Marketing Central's checkout module uses an abstraction layer for payment processing. The payment interface defines the contract (tokenize card, authorize amount, capture, refund); the implementation is the specific processor. This means processor selection does not require architectural changes — it requires implementing one adapter behind the abstraction layer.
PCI Approach
The processor's hosted payment fields or client-side JavaScript SDK handles card data capture. Card numbers never enter Marketing Central's servers. The processor issues a payment token; Marketing Central stores and operates on the token only. This keeps Marketing Central out of PCI DSS card data scope. The estimate assumes a standard REST API processor integration.
Authentication (Entra)
Microsoft Entra ID + Entra External ID
Enterprise identity (corporate) + external identity (franchise + vendor) — both in Liberty's existing tenant
Corporate Identity (Entra ID)
Liberty's internal users (Marketing, Admin, Corporate View) authenticate via the existing Entra ID tenant. Marketing Central registers as an Entra application, receives JWT tokens on successful authentication, and uses the role claims in those tokens for RBAC enforcement. MFA, conditional access, and session policies inherit from Liberty's existing Entra configuration — no separate setup.
External Identity (Entra External ID)
Franchisees and vendors authenticate via Entra External ID. This is a distinct identity pool within Liberty's Entra tenant, designed for external (B2B/B2C) users. Franchisee accounts are provisioned by admin or invited via email flow; vendors are provisioned by admin. The login experience is branded to Liberty and integrated with the LRC SSO entry point.
Entra ID federates with Liberty's existing Active Directory and provides single sign-on over SAML 2.0 (and OIDC). Marketing Central consumes that federation rather than maintaining its own user store, so corporate users carry their existing Liberty identity into the platform with no separate login — satisfying the RFP's SAML 2.0 SSO requirement directly.