I replaced a discontinued legacy system with one Salesforce platform covering sales, registration, delivery, billing, and reporting.

Technology Manager & Salesforce Platform Owner · UCLA Anderson School of Management, Executive Education · Built and refined Dec 2022–2026

UCLA Anderson Executive Education sells open-enrollment programs to individuals and custom programs to corporate clients. Its work runs from CRM Sales and Marketing, such as lead and opportunity management, through program design, registration, session delivery, faculty and AV coordination, invoicing, payment, and financial reporting. When the long-standing legacy system, 'Flatbridge', was discontinued, those workflows were spread across spreadsheets, forms, and manual processes. Re-keying data and reconciling by hand made it hard to see invoiced amounts, payments, balances, and how each program was performing. The B2C and B2B sides also needed different pricing, participant, and payor patterns.

My approach

I led the in-house design, build, and rollout of a Salesforce Enterprise Edition platform and handled discovery, data modeling, automation, testing, and production support.

• One operational backbone: Opportunity stayed the commercial entry point. From there, Program served as the operating and financial hub, Registration as the participant transaction, Session as the unit of delivery, and Invoice → Payment → Line Item as the billing chain.

• Separation of concerns. The model uses Opportunity plus six custom objects, with 276 custom fields, 22 roll-up summaries, and 26 custom relationships. I used master-detail relationships wherever ownership and aggregation mattered.

• Participant ≠ payor. Modeling the 'attendee' and the person paying separately supports employer, sponsor, and third-party billing without overwriting the participant’s identity.

• Declarative first. A record-triggered Flow creates a Registration from an Opportunity, with duplicate prevention and a deletion-state reset so a deleted record can be replaced cleanly. Validation rules block registration for programs that have already ended. I used code only where it was justified, for branded Visualforce invoice PDFs that run on standard controllers with no custom Apex to maintain.

• Clear financial states. Expected, invoiced, collected, and outstanding amounts stay distinct, so pipeline, billing, and cash are never mixed together in reports.

• Connected touchpoints. FormAssembly registration and lead forms, Account Engagement campaigns, and Transact Campus payment fields (payment links, item codes, GL references, and transaction IDs) keep every transaction traceable back to Salesforce.