Plaza Premium Group · Digital Platform

Act I · The thesis

Three workflows. Three apps. One audit trail.

PPG's commercial engine spans deal intake, contract execution, lounge operations, and incentive payout. Today each of these lives in a different system — or no system at all. We unify them around a shared identity, security, and audit fabric.

Top-down synthesis

PPG should build three coordinated apps on a single Power Platform tenant — MDM for master data, CAW for commercial approval, SIN for sales incentives — sharing common identity, security, audit, and AI fabric. Configuration-first, not custom-coded. Agentic, not just automated. Audit-grade, by default.

The problem

Approvals routed through email and spreadsheets. Pricing models inconsistently applied. Renewals tracked manually. Incentives calculated in Excel. No single source of truth for partners, contracts, or outlets.

Revenue leakageAudit gaps

The opportunity

A unified Power Platform tenant with shared Dataverse, Entra ID, and audit. Replace fragmented tooling with three governance-led apps that talk to each other through a common data spine.

Single tenantShared fabric

The principle

Configuration over code. Roles and thresholds editable by business admins, not engineers. AI as an overlay that augments human decisions — not a black-box replacement for them.

Config-ledHuman-in-loop

Act II · The three apps

Each app owns one domain. All share one fabric.

Three purpose-built apps on Microsoft Power Platform — Power Apps · Dataverse · Power Automate · Power BI. Each card below tells the same story: what we'll do, why it matters, how we build it, what sets it apart, the end-to-end flow, the key features, and the requirement trace.

⚠ Problem

What needs to be done — the pain points we eliminate

⚙ Approach

What we'll build — architecture & building blocks

★ Value

Why this matters — measurable business outcomes

✦ Differentiation

What sets it apart — defensible advantages

🗂

App 01 · MDM · Bamboo Technologies

Master Data Management

Single source of truth for Partners · Contracts · Outlets · Rates — with full Maker/Checker governance, effective dating, and cross-system reconciliation.

Spec: PPG_MDM SRS v2.1 + BRD + Project Scope + Tech Spec v2.3 Migration scope: Partners 200 · Contracts 600 · Outlets 1400 Entities: Partner · Contract · Outlet · Rate Plan · LMS · IBE · Smart Traveller Stack: Power Platform Model-Driven · Power Automate · JavaScript

⚠

The Problem

What needs to be done

PPG operates Plaza Premium Lounge (PPL), Plaza Premium First (PPF), and 3rd Party Lounges (3PL). It needs to onboard 3PL partners, govern its own outlet master data, and migrate Partners 200 · Contracts 600 · Outlets 1400 from existing sources — without a structured system to do so today.

No single record of Partner / Contract / Outlet / Contract Rate Plan / LMS / IBE / Partner Portal / Smart Traveller (SRS §2.2)
No formal Maker / Checker workflow with audit history
No view of what edits changed (no before/after)
Downstream apps (CAW · LMS · Finance) need a governed authoritative source

⚙

Our Approach

What we will build

Per SRS v2.1 §1 footer: Power Platform Model-Driven App framework with out-of-the-box components. Power Automate for approval flows. JavaScript for custom calculations and granular permission controls. The 9-state status model (SRS §3.3) handles both create and modification cycles.

9 statuses (§3.3): New · Submitted · In Effect · Rejected · Returned · Modification Submitted · Modification Returned · Modification Rejected · Wait for change to take effect
Maker / Checker separation of duties with OSA (Outlet Setup) follow-up
Master Data Comparison & approval view (§4.13) for Partner / Contract / Outlet edits
Read-only API / JDBC / Driver connectivity to PPG AWS Enterprise Data Hub (§2.2)

★

Value to PPG

Why this matters

Single record — Partner / Contract / Outlet / Rate consumed by all downstream PPG systems
Audit history — every status transition logged per §3.3 with actor + timestamp
Migration enabled — Partners 200 · Contracts 600 · Outlets 1400 lifted into one governed store (§2.2)
3PL onboarding accelerated — Bulk upload via template (§2.2)
Operational visibility — Power BI Operation Report (status of contract & outlet), Delta Report (recent changes), Form Completion Report (§2.2 · §4.17)

✦

Differentiation

What sets it apart

Purpose-built for PPG's domain — PPL / PPF / 3PL distinction native to the data model
Modification cycle as first-class — 4 statuses dedicated to modifying in-force master data (§3.3)
OSA hand-off step — after Checker approval, OSA completes outlet setup before "In Effect"
Master Data Comparison view (§4.13) compares prior vs proposed values inline
Direct AWS EDH integration (read-only API/JDBC) per §2.2 — downstream PPG analytics consume direct

→High-level flow · 9 statuses per SRS §3.3

01

New

Master data initiated by Maker · status = New

›

02

Submitted

Maker clicks Submit · routes to Checker

›

03

Checker decision

Approve → In Effect · Reject · Return

›

04

In Effect

Waiting for OSA to complete outlet info

›

05

Modification Submitted

User edits in-force data · returns to Checker

›

06

Wait for effect

Modification approved · awaits effective date

›

07

Data Updated

Effective date reached · downstream consumers refreshed

◆Key features · with SRS section refs

📋

To-do List

§4.1 · pending tasks/approvals routed to the user

👥

Partner List + Details

§4.2 / §4.5 · 9-state lifecycle

📜

Contract List + Details

§4.3 / §4.6

🏢

Outlet List + Info + Facilities

§4.4 / §4.7 / §4.8 · IATA · operating hours · facilities

💲

Contract Rate + Indicative

§4.9 / §4.10 · tiered + non-tiered

⚖

Master Data Comparison

§4.13 · prior vs proposed inline diff for approval

📱

LMS & Smart Traveller

§4.12 / §4.15 · 18 devices

📊

Power BI Reports

§4.17 · Operation · Delta · Form Completion

Requirement traceability — SRS

SRS 4.2 Partner ListSRS 4.3 Contract ListSRS 4.4 Outlet ListSRS 4.5 Partner DetailsSRS 4.6 Contract DetailsSRS 4.7 Outlet InfoSRS 4.8 FacilitiesSRS 4.9 Contract RateSRS 4.10 Indicative RateSRS 4.11 Check Master DataSRS 4.12 LMSSRS 4.15 Smart TravellerSRS 3.3 Status (9 states)

📋

App 02 · CAW · TechnePlus SOW v1.5 (Thread 1)

Commercial Approval Workflow

Deal intake → multi-level approval → CMS handoff → LMS enablement. Replaces fragmented email + spreadsheet workflows with a governed, auditable, configurable digital platform.

Spec: CAWSI Req v1.4 (PPG comments, Leann Yong, 22 Apr 2026) Capacity: 200 concurrent users · 150 sales users · 2,000 contracts Roles in spec: Sales · Sales Mgmt · Sales Admin · Finance · Operations · Marketing Volume growth: +15% / yr · 600 lounges · 4,800 AIs

⚠

The Problem

What needs to be done — per CAWSI §1 Objectives

Three objectives per spec §1: Digitization & Data Structuring (transform static contract documents and complex pricing models into structured data), Establish a scalable data foundation (drive revenue optimization & billing automation), Internal Governance (strengthen end-to-end execution control, ensure approved terms execute accurately, enhance auditability through a centralized digital trail).

Sales captures opportunities in Zoho CRM but approvals tracked via email + spreadsheets (§3.1)
Multi-pricing-model contracts (unit · tier · zone · country-wise · MAG · prepay · rebate) not systemized (§3.2.1)
Approval matrix bands X/Y/Z + 5 approvers (CSO→CCO→DCEO→CFO→CEO) maintained manually (§3.2.2)
Country CPI tables maintained manually monthly (§3.2.5)
Outlet Minimum Price has access rules by client segment + sales role — needs CLS enforcement (§3.2.6)

⚙

Our Approach

What we will build — per TechnePlus proposal §3

Microsoft Power Platform across the stack: Power Apps (Sales · Finance · Approver · Admin role-based apps), Dataverse (Commercial Approval + Lines + Pricing Policies + CPI/Outlet Libraries + Approval Matrix + Approval History + Currency Rates), Power Automate (Zoho intake · approval routing · CMS/LMS handoffs · renewal schedulers), Power BI (RLS/CLS-aligned datasets).

3 paths · A / B / C — auto-numbered A####/B####/C#### per nature
17 screens — 9 user-facing (CA-01..CA-09) + 6 admin + 2 reporting/governance
11 orchestrations — Zoho intake · Legal Review · HQ Sales · Finance · Approval Matrix · Resubmission · CMS handoff · LMS handoff · 2× renewal · CPI update
12 notification templates, 8 dashboards, ~200 Zoho Closed-Won migrated (§3.2.10)
RLS + CLS across Dataverse · Power Apps · Power BI (§3.2.7)

★

Value to PPG

Why this matters — mapped to §3 scope by audience

Sales — track approval & signing progress in real-time · automate Admission Instruction creation · aware of AI readiness in LMS
Sales Management — streamline approval, historical audit trail, reassign account ownership, automate contract expiration alerts
Finance — single source of Client Masters · identify duplicates & parent-child hierarchies · real-time contract status awareness
Operations — awareness of new/delisted clients for capacity management & staff training
Marketing — awareness of new clients for local marketing (logos on digital screens)

✦

Differentiation

What sets it apart — anchored in spec features

Pre-approved Price Grid auto-approval (§3.2.2) — Outlet Minimum Price compliance bypasses approval but is still captured
4 value bands × 5 approver sequence (§3.2.2) — CSO → CCO → DCEO → CFO → CEO, configurable by admin without code (TechnePlus Request to SI 2)
3 CPI renewal formulas (§3.2.4) — CPI · max(CPI, X%) · CPI+X% capped at Y%
Outlet Min Price CLS (§3.2.6) — visible to Reviewer/Approver only, gated by client segment access matrix
Embedded CPQ configurator — Salesforce-style Product × Price Book × Discount Schedule × live margin lives inside Sales Intake Step 3 (no separate quote step before approval)
Workflow Designer no-code (§5.1.2) — add levels, parallel/sequential steps, reassign, retire approvers without code changes

→High-level flow · per CAWSI §3.1 + TechnePlus end-to-end

01

Zoho Intake

API integration · Owner / Account / Tentative dates / Currency

›

02

Sales Intake CA-01

Auto-number A####/B####/C#### · 5-step wizard with embedded CPQ configurator

›

03

HQ Sales / Finance

CA-03 / CA-04 · pricing alignment · USD-derived for Finance

›

04

Approval Matrix CA-05

Band X/Y/Z · CSO→CCO→DCEO→CFO→CEO sequence

›

05

CMS Handoff CA-06

ContractApproved payload · retry/backoff + DLQ (§8)

›

06

CMS draft + Legal

Legal Review if non-PPG template / clause changes (§V.g)

›

07

Signed → LMS

Notify LMS team · create Admission Instruction (AI)

◆Key features · CAWSI / TechnePlus section refs

🔀

3 Paths · A/B/C

New Contract · New Opening · Renewal — drives mandatory sections

📐

7 Pricing Models

§3.2.1 · unit · tier (cumulative + per-portion) · zone · country B2C+B2B2C × 2/3/6h · MAG · prepay · rebate

📈

3 CPI Formulas

§3.2.4 · CPI · max(CPI,X%) · CPI+X% capped at Y%

🌍

CPI Library

§3.2.5 · IMF + 9 national stats sites · monthly manual update

🗳

Approval Matrix

§3.2.2 · 4 bands · 5 approvers · auto-approval via Price Grid

🔒

Min Outlet Price CLS

§3.2.6 · 4 client segments × access matrix (Local/Global/Finance)

🔗

8 Interfaces

§3.2.3 · Zoho · CMS · LMS · SI · PRPS · 3PL MDM · PPL/PPF MDM · iPaaS

⚖

Legal Review (Pre-/Post-CMS)

TechnePlus §V.g · non-PPG template / clause changes / Sales-flagged

💲

Embedded CPQ (Step 3)

Product × Price Book × Discount Schedule · live margin · routing-impact preview · all inline in Sales Intake

Requirement traceability — Spec + Proposal

Req 3.2.1 Commercial TermsReq 3.2.2 Approval MatrixReq 3.2.3 InterfacesReq 3.2.4 Renewal + CPIReq 3.2.5 CPI LibraryReq 3.2.6 Outlet Library + CLSReq 3.2.7 Access ControlProposal §S.a–§S.f CA-01..09§V.a–V.h Validations§Br.a–Br.f Branching§6 Dataverse ERD§8 Integration · DLQ

🎯

App 03 · SIN · TechnePlus SOW v1.5 (Thread 2)

Sales Incentive Program

Automated eligibility · calculation · statements — derived from approved commercial transactions. 6 personas, gamified leaderboard, audit-grade payouts. Salesforce-class UX.

Spec: CAWSI Req §4 · 5 schemes · 3-level caps Disbursement: Half-yearly into payroll, actual revenue from Finance (§4.2.7) Approval: Finance (Commercial Sales) → Chief Sales Officer (§4.2.6) Future interface: PRPS (PAX Revenue Processing System)

⚠

The Problem

What needs to be done — per CAWSI §4.2.5 Current State Challenges

The spec is explicit about current-state pain. Lifted directly from §4.2.5:

One qualified incentive submission may cover up to 3 half-yearly batches (min 12-month contract term)
Multiple data sources — Power BI, internal sales report, finance system — manually reconciled
Limited visibility on Investment Committee (IC) sales revenue target for the 1st month and first 3 months after new location opening
Limited visibility on Incentive Utilization per location / client / individual
Limited visibility on Outlet opening / effective date
Difficulty in managing scenarios involving different schemes where incentive payouts vary

⚙

Our Approach

What we will build — per spec §4.2 + TechnePlus Thread 2

Spec §4.2.5 Request to SI 3 sets the bar: "Normalize and parameterize the existing calculation rules to enable a design that can accommodate unlimited schemes, scenarios, parameters, eligibility criteria, rates, tiers and caps." The build delivers exactly this — Dataverse plan/slab/rule configured via Admin UI, no hard-coding.

Eligibility Engine (§4.2.1) — min contract term · signed-date filter · signing-entity filter · Key Roles confirmation
Role Allocation (§4.2.2) — Deal Owner/Closer X% + Key Account Owner Y% + Supporter Z% = 100%
Cap Mgmt (§4.2.3) — Individual by level (Director / AssocDir+SrMgr / Manager-), Client USD/client, Outlet USD/location
5 Schemes A–E (§4.2.4) — parameterized, admin-editable
Approval Matrix (§4.2.6) — Finance Review → Chief Sales Officer Approve, configurable

★

Value to PPG

Why this matters — mapped to CAWSI §3 features by audience

Sales — "Automate sales incentive eligibility based on My Accounts" · "Real-time alerts and updates on new locations"
Sales — "Interface to PRPS to generate a daily view of revenue and estimated incentives"
Sales Management — "Review and report on individual and team sales achievements"
Finance — "Interface to PRPS to streamline sales incentive and billing calculations through data-driven automation"
Audit lineage — every payout traces back to approved commercial terms (§4.1 workflow)

✦

Differentiation

What sets it apart — features lifted directly from spec

5 schemes covering every PPG commercial scenario (§4.2.4) · A New Contract · B New Opening early (within 3 mo) · C New Opening late (after 3 mo) · D Renewal local · E Renewal global
Three-level cap enforcement (§4.2.3) — Individual + Client + Outlet, not just one
CPI-linked renewal schemes (§4.2.4) — Scheme D rewards revenue exceeding Country CPI by ≥1pp; Scheme E rewards revenue exceeding 6% global increment
Half-yearly disbursement aligned with Finance billing cycle (§4.2.7) · directly into Sales payroll bank
PRPS-ready architecture — §4.2.8 API Interface designed for the to-be PAX Revenue Processing System

→High-level flow · per CAWSI §4.1 Workflow

01

Approved & Signed

Latest approved CAW data + CMS contract signing event

›

02

Auto-capture

"Application shall automatically capture all qualified submissions" (§4.1)

›

03

Eligibility Engine

§4.2.1 · contract term · signed date · signing entity · Key Roles

›

04

Scheme + Calc

§4.2.4 · scheme A–E selects rate · revenue base computes raw

›

05

Cap + Allocate

§4.2.3 caps + §4.2.2 allocation to Deal Owner / Key Acct / Supporter

›

06

Finance Review

§4.2.6 · Finance (Commercial Sales) → Chief Sales Officer

›

07

Half-yearly Disbursement

§4.2.7 · into Sales payroll bank · actual revenue from Finance

◆Key features · with §4 section refs

🎰

Scheme A · New Contract

§4.2.4 · A% of revenue first 12 mo · Client cap

🎰

Scheme B · Opening early

§4.2.4 · 80% of pro-rated Y1 IC target · within 3 mo · Outlet cap

🎰

Scheme C · Opening late

§4.2.4 · 100% of Y1 IC target · after 3 mo · Outlet cap

🎰

Scheme D · Renewal local

§4.2.4 · D% of revenue exceeding Country CPI ≥1pp · Client cap

🎰

Scheme E · Renewal global

§4.2.4 · E% of revenue exceeding 6% increment · Client cap

👥

Key Roles · 100%

§4.2.2 · Deal Owner/Closer + Key Account Owner + Supporter

🚧

3-Level Caps

§4.2.3 · Individual (% basic by level) · Client (USD) · Outlet (USD)

📅

Half-yearly Batch

§4.2.7 · paid every 6 mo · up to 3 batches per submission

Requirement traceability — Spec §4

Req 4.2.1 Eligibility EngineReq 4.2.2 Role AllocationReq 4.2.3 Cap ManagementReq 4.2.4 Schemes & CalcReq 4.2.6 Approval MatrixReq 4.2.7 DisbursementReq 4.2.8 API InterfaceReq 4.2.9 Access ControlProposal §S.f.i–iv§6 ERD · IncentivePlan/Slab/Rule/Earning/Statement/CalculationLog

Act III · The architecture

A layered platform with one data spine.

External systems feed three apps. Three apps share one Dataverse spine. One Power Platform foundation handles identity, security, and audit. Animated arrows below show real data flows.

Exhibit 1 · Architecture · System landscape

External systems → Three apps → One Dataverse spine → Power Platform foundation

Five architecture principles

What the architecture commits to.

One identity, one audit

Single Entra ID directory. Eight security roles span all three apps. Every action — every field change — captured with before / after / actor / timestamp into one immutable log.

Dataverse as the spine

22 entities across MDM, CAW, SIN. Foreign keys keep apps in lockstep. No app reads or writes its own private store — everything flows through one platform.

Configuration over code

Approval matrices, pricing policies, incentive plans, and CPI tables are edited by business admins through guarded admin UIs. Engineers do not redeploy when policy changes.

Integration with retry & dead-letter

Every outbound call to Zoho, CMS, LMS, PRPS has exponential backoff and a dead-letter table. No silent failures. Operators reconcile from a queue, not from emails.

AI as an overlay

Six background agents and three copilots run alongside the apps — they read live Dataverse via function tools and propose, never decide unilaterally. Human-in-the-loop everywhere.

Multi-environment ALM

Managed solutions deployed Dev → Test → UAT → Prod. CI/CD pipelines. Versioned releases. Change Advisory Board approval gate for production.

Exhibit 2 · Integration matrix

How information actually moves.

Eight integration links. Each tagged real-time (event-driven) or batch (scheduled). Resilience patterns vary by link: retry / backoff / dead-letter for outbound; idempotent upsert for inbound.

Source

Zoho CRM → CAW

Opportunity records flow from Zoho on a 15-minute schedule. CAW preloads the Sales Intake Wizard with account, owner, currency, projection, and amount fields.

batch · 15minOAuth2 refresh

Reference

MDM → CAW

Outlet Library (with CLS-protected minimum prices), Partner directory, Country / Currency / IATA lookups. CAW reads in real time on form load.

real-time · DataverseCLS-secured

Downstream

CAW → CMS

ContractApproved payload triggered on final approval. Carries client, contract terms, pricing lines, signing entity. CMS generates the draft contract.

event-drivenretry · DLT

Callback

CMS → CAW

Signed callback. CAW marks the approval as Signed, triggers LMS notification, flags the deal as incentive-eligible.

event-drivenwebhook

Downstream

CAW → LMS

After signing, CAW notifies LMS to provision Admission Instructions (AI buttons) on lounge tablets for the new partner program.

event-drivenretry · DLT

Eligibility

CAW → SIN

SIN listens for approval/signing events on Dataverse. On trigger, derives the scheme (A–E), computes earnings, allocates across deal roles, enforces caps.

event-driven · same tenant

Revenue

ERP / PRPS → SIN

Monthly revenue feed per outlet per approval. Used by SIN to calculate booking-based and billing-based incentives, and to true-up estimates.

monthlyplanned (PRPS)

Analytics

All apps → Power BI

RLS / CLS-aligned datasets with incremental refresh. Dashboards: pending approvals, agreement registry, pricing adjustments, sales rep performance, anomaly reports.

refresh · 15minRLS aligned

Act IV · Governance

Audit-grade by default. Not by exception.

Four layers of controls — from authentication at the perimeter to immutable audit at the core. Every layer enforced by the platform, not by policy alone.

01

Authentication & SSO

Entra ID at the perimeter · MFA · conditional access

02

Role-Based Access Control

8 roles · Maker/Checker segregation · least privilege per app

03

Row & Column-Level Security

RLS by region · CLS protects Min Outlet Price, margin indicators, override flags

04

Immutable Audit Trail

Append-only · before / after / actor / timestamp · 7-year retention · supports SOX / GDPR

What it enforces

Six operational guarantees.

Segregation of duties

Maker initiates · Checker approves · Approver authorizes. No single user can do all three on the same record.

SLA-driven escalation

Approval steps have SLAs (24h / 48h / 72h). Breaches escalate to fallback delegates automatically.

Delegation with audit

Planned absences trigger delegated approvers with full log. No "approve on behalf of" in email.

Maker can't see min price

Column-level security hides Minimum Outlet Price from Sales — visible only to reviewers/approvers.

No silent failures

Failed integrations to CMS / LMS / Zoho / PRPS go to a Dead-Letter Table with correlation ID for human triage.

Yellow-field resubmission

When a deal is returned, only pre-designated fields are editable. Reviewer sees a compare view before re-approving.

Act V · The AI overlay

Nine agents augment human decisions.

Three in-app copilots (one per app) plus six background agents. All grounded on live Dataverse via function tools — they read real records, not their training data. Humans always decide; AI proposes.

Azure OpenAI

PPG Copilot Core

gpt-4.1 · tool-calling on live Dataverse

CAW · agent

Validation

Pre-submit checks · missing fields · CLS guards

CAW · agent

Routing

Picks band X/Y/Z · sequences approvers

CAW · agent

Pricing

Recommends from similar approved deals

CAW · agent

Renewal

Predicts likelihood · suggests CPI uplift

CAW · LLM

Risk Analyzer

Flags non-PPG clauses in contract drafts

SIN · agent

Anomaly Detector

z-score on incentive payouts per scheme

MDM · copilot

Steward Assistant

Find dupes · explain status changes

In-app copilots

One per app. Chat sidebar bound to the user's role. All responses cite the record IDs they used. Sales users cannot extract CLS-protected fields through the copilot.

MDMCAWSIN

Background agents

Run on triggers (submit, approve, sign) or on demand. Output structured findings — never free-text decisions. Humans approve / override every output.

ValidationRoutingPricingRenewal

LLM-bounded scope

Function calling restricts what the LLM can read. Cannot bulk export. Cannot call other LLMs. Cannot bypass RLS / CLS. Every tool call logged with correlation ID.

Function toolsAudited

Act VI · Delivery

Two threads. Six months. Phased go-lives.

CAW leads. SIN follows in lockstep, depending on CAW's commercial data foundation. MDM has already gone live (Sprints 1+2 by Bamboo) and feeds reference data into both.

Exhibit 3 · Phased delivery · Week 1 to Week 20

Two coordinated execution threads, one shared release cadence

Month 1

Month 2

Month 3

Month 4

Month 5

Thread 1 · CAW

3,700 hrs · 16 weeks · Go-Live W14

Foundation · 6w

Build & Integration · 6w

UAT · 4w

Go-Live + Hypercare · 4w

Thread 2 · SIN

2,100 hrs · starts W7 · Go-Live W17

Foundation · 4w

Build & Integration · 5w

UAT · 3w

Hypercare · 2w

Separate · MDM

By Bamboo · Sprints 1+2 live

Already in production · provides Outlet Library, Partner directory

Foundation

Build & Integration

UAT

Hypercare

Go-Live milestone

Why this order

SIN cannot be calculated until CAW's commercial data is stable. So SIN starts 2 weeks into CAW Phase 2 once the core data model is locked, and goes live 3 weeks after CAW.

Why phased UAT

Each phase has entry/exit criteria and stakeholder sign-off from Sales, Commercial, Finance, IT Security. No "big bang" production cutover — managed solution deployment per release.

Why hypercare

4 weeks for CAW, 2 for SIN. Daily monitoring of integration flows, SLAs, approval routing, renewal triggers. Real-time war-room support before steady-state handover.

Act VII · The outcome

What changes for PPG.

Before · Today

A fragmented commercial operating model.

Approvals tracked over email and Excel
No central view of pending deals or SLAs
Pricing models applied inconsistently across regions
Renewal pricing computed manually
Incentives calculated in spreadsheets — disputes common
No audit trail beyond email forwarding
Master data inconsistent across LMS, IBE, finance systems

→

After · 2026

A unified, AI-augmented governance fabric.

Approvals routed automatically per value band with SLA timers
Real-time pipeline visibility · agreement registry
Pricing models enforced by configuration · no manual interpretation
CPI renewals computed automatically from IMF data
Incentives calculated from approved data · auditable PDF statements
Every change captured · before/after diffs available
MDM as single source of truth · reconciled to LMS and IBE

Targeted outcomes

What the business should see in 12 months.

~40%

Faster approval cycles

Replacing email + spreadsheets with SLA-driven workflows cuts deal cycle time materially. Routing Agent eliminates manual band lookup.

~25%

Lower revenue leakage

Min-price CLS enforced at the line level. Pricing Recommender flags below-peer-median deals before they get submitted.

100%

Audit coverage

Every approval, override, and amendment captured with before / after / actor / timestamp. Supports SOX, GDPR, and internal audit.

Zero

Incentive disputes

Earnings derived deterministically from approved commercial data. Calculation log shows every step. Finance signs off on system output, not Excel.

From email chains to a single governance fabric.One platform. Three apps. Built for audit.

Three workflows. Three apps. One audit trail.

The problem

The opportunity

The principle

Each app owns one domain. All share one fabric.

Master Data Management

Commercial Approval Workflow

Sales Incentive Program

A layered platform with one data spine.

What the architecture commits to.

One identity, one audit

Dataverse as the spine

Configuration over code

Integration with retry & dead-letter

AI as an overlay

Multi-environment ALM

How information actually moves.

Audit-grade by default. Not by exception.

Six operational guarantees.

Segregation of duties

SLA-driven escalation

Delegation with audit

Maker can't see min price

No silent failures

Yellow-field resubmission

Nine agents augment human decisions.

In-app copilots

Background agents

LLM-bounded scope

Two threads. Six months. Phased go-lives.

Why this order

Why phased UAT

Why hypercare

What changes for PPG.

Before · Today

After · 2026

What the business should see in 12 months.

From email chains to a single governance fabric.
One platform. Three apps. Built for audit.