Solution: Pinnacle Consulting Group

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Architecture Decisions

AD-1: Single Enterprise Org with Sales Cloud and Platform Licenses

Decision: Upgrade the existing Salesforce org from Professional edition to Enterprise edition. Provision Salesforce (Sales Cloud) licenses for sales users. Delivery operations staff, consultants, HR, and finance receive Salesforce Platform licenses; they require custom object access but do not need case management, entitlements, or the service console.

Rationale: Professional edition lacks the features this solution requires: no Apex (blocking programmatic sharing), no Flow Builder for advanced automation, no custom REST API access (blocking Harvest integration), and no granular sharing rules needed for record-level client isolation. PE does have basic permission sets, but lacks the permission set groups and object-level sharing granularity Enterprise provides. Enterprise edition is the minimum viable tier. The existing org can be upgraded in-place; no new org is needed, which preserves the 4-year account history and avoids a net-new Salesforce contract during the first 4 weeks.

License breakdown:

User Group	Count	License Type	Rationale
Sales team	~20	Salesforce (Sales Cloud)	Full opportunity pipeline access
Delivery operations	~20	Salesforce Platform	Project views, resource management; no case management or service console needed
Consultants (billable)	140	Salesforce Platform	Time entry visibility, resource profile, no CRM features needed
HR / Finance / Admin	~20	Salesforce Platform	Object access via permission sets

Salesforce Platform licenses cost less than full CRM licenses and cover custom object access, which is all most consultants and internal staff need. The 200-seat count fits within a single org without multi-org complexity.

Risk: Salesforce Platform licenses include read access to Accounts and Contacts but exclude Opportunities, Forecasts, and other Sales Cloud objects. The data model must place project and resource objects as custom objects so Platform-licensed users can reach them without requiring Sales Cloud object permissions. Validate the full object permission matrix in the first 4 weeks.

Decision: Set Org-Wide Default (OWD) to Private on Project__c, Project_Assignment__c, and NDA_Document__c. Time_Entry__c is a Master-Detail child of Project__c and therefore inherits Project__c sharing automatically (Controlled by Parent); no independent OWD is set. Use criteria-based sharing rules for predictable broad grants (e.g., all records in a given office are visible to that office’s practice lead). Use Apex-managed sharing for the dynamic case: when a consultant is added to a project assignment, programmatic sharing grants them access to the parent project record.

Rationale: Requirement 7 demands hard record-level isolation between client engagements. OWD Public or Controlled by Parent on these objects would expose all project records to all authenticated users, which violates the core client confidentiality guarantee. Starting at Private and opening up selectively via sharing is the only defensible pattern.

AD-3: Business Unit Separation via Role Hierarchy: No Multi-Org

Decision: Model the three offices as distinct branches in the role hierarchy under a single VP of Delivery node. Use permission set groups to differentiate the delivery operations experience from the sales experience within the same org.

Rationale: Requirement 1 mandates a single org. Requirement 2 calls for business unit separation without creating an unmanageable permission set sprawl. A well-structured role hierarchy with office-level branches delivers reporting rollup and visibility inheritance without org proliferation.

AD-4: Microsoft Entra ID SSO via SAML 2.0, No Local Passwords

Decision: Configure Salesforce as a SAML 2.0 service provider with Microsoft Entra ID (formerly Azure Active Directory) as the identity provider. Set the My Domain policy to block all non-SSO login methods for internal employees. Service accounts for integration middleware receive Named Credentials (OAuth 2.0 client credentials) rather than interactive SAML authentication.

Rationale: Requirement 5 requires company-wide SSO. SSO via SAML 2.0 eliminates the need for users to manage separate Salesforce passwords, though Salesforce usernames still exist as system identifiers. SAML 2.0 is the current Salesforce-recommended pattern for Entra ID integration and is supported natively. The “Prevent login from login.salesforce.com” setting combined with a My Domain login policy enforces SSO-only access without custom code.

AD-5: Harvest Integration via Scheduled MuleSoft Flows (Middleware-Mediated)

Decision: Use MuleSoft Anypoint Platform as the integration middleware between Harvest and Salesforce. Schedule polling flows to run every 60 minutes during business hours. Configure Harvest webhooks to POST time entry events to a MuleSoft HTTP listener for the real-time 80% threshold alert path (requirement 21).

Rationale: The Harvest REST API is well-documented. A direct Salesforce-to-Harvest callout (Apex scheduled job) is technically feasible but puts the retry/queue logic inside Salesforce, which complicates error handling for requirement 23. A middleware layer handles queuing, deduplication, and graceful degradation more cleanly and keeps Salesforce apex limits headroom available for other automations. This also leaves the integration pattern extensible if additional systems are added later.

AD-6: Lightning App Builder for Differentiated UX per Audience

Decision: Create two Lightning Apps: Pinnacle Sales (focused on accounts, contacts, opportunities, and staffing plan attachments) and Pinnacle Delivery (focused on projects, resource profiles, utilization, and time entries). Assign each Lightning App to the relevant permission set group.

Rationale: Requirement 4 calls for a differentiated experience. Lightning Apps with customized navigation, record page layouts, and page-level component visibility handle this without forking the data model or building custom UI. No Aura/LWC custom nav shell is needed at this scope.

System Landscape

BambooHR Integration

BambooHR remains the HR system of record through Phase 2. A formal integration is out of scope for this program. Skills and certification data are manually loaded into Salesforce resource profiles during Phase 2 onboarding. A future integration ADR should address bidirectional sync once the platform stabilizes.

Data Model

Core Custom Objects

Project__c: One per client engagement. Relates to Account (Lookup). A Lookup relationship (not Master-Detail) is required so that Project__c can have its own OWD (Private) and support Apex managed sharing via the Project__Share table. A Master-Detail to Account would force Project__c to inherit Account’s sharing, preventing independent record-level isolation.

Field	Type	Notes
Project_Name__c	Text(255)	Required
Start_Date__c	Date	Required
End_Date__c	Date	Required
Contracted_Hours__c	Number	Budget baseline for threshold alerts
Billing_Type__c	Picklist	Fixed-Fee, Time-and-Materials
Project_Manager__c	Lookup(User)	Drives alert notifications; req 16
Office__c	Picklist	SF, Chicago, Austin; business unit tag
Status__c	Picklist	Active, Closed, On Hold

Resource_Profile__c: One per consultant. Relates to User (Lookup, non-Master-Detail to allow Platform license users to be record owners).

Field	Type	Notes
Consultant__c	Lookup(User)	1:1 with User record
Weekly_Availability_Hours__c	Number	Updated by PM or automation
Current_Utilization_Pct__c	Formula	Derived from active assignments
Office__c	Picklist	Drives office-level reporting

Skill__c: Child of Resource_Profile__c (Master-Detail).

Field	Type	Notes
Skill_Category__c	Picklist	Backend, Cloud, ERP, etc.
Skill_Name__c	Text(255)
Proficiency_Level__c	Picklist	Beginner, Intermediate, Expert

Certification__c: Child of Resource_Profile__c (Master-Detail).

Field	Type	Notes
Certification_Name__c	Text(255)
Expiration_Date__c	Date	Drives 60-day alert; req 17
Certification_Body__c	Text(100)

Project_Assignment__c: Junction between Project__c and Resource_Profile__c.

Field	Type	Notes
Project__c	Master-Detail(Project)
Resource_Profile__c	Lookup(Resource_Profile)
Role_on_Project__c	Picklist	Lead, Consultant, Support
Assignment_Start__c	Date
Assignment_End__c	Date	Drives 24-hour access revocation; req 12
Is_Active__c	Formula(Boolean)	Assignment_End >= Today

Time_Entry__c: Synced from Harvest. Child of Project__c (Master-Detail).

Field	Type	Notes
Harvest_Entry_Id__c	Text(50)	External ID; prevents duplicate sync
Consultant__c	Lookup(User)	Links to consultant
Entry_Date__c	Date
Hours_Logged__c	Number
Billing_Period__c	Text(20)	YYYY-MM format for billing report grouping
Synced_At__c	DateTime	Last sync timestamp

NDA_Document__c: Child of Project__c or Account (configurable). Uses Salesforce Files with sharing enforced by ContentDocumentLink and parent record OWD.

Integration Architecture

Harvest Time Tracking Sync

Direction: Harvest to Salesforce (unidirectional for Phase 3). Salesforce does not write back to Harvest.

Scheduled sync path (requirement 20):

MuleSoft scheduled flow runs every 60 minutes, Monday through Friday, 6 AM to 8 PM local time.
Flow queries Harvest REST API /time_entries with a updated_since filter using the last successful sync timestamp stored in MuleSoft Object Store.
Each time entry is upserted into Time_Entry__c using Harvest_Entry_Id__c as the external ID. Upsert prevents duplicates on retry.
After each upsert batch, MuleSoft invokes a Salesforce Platform Event TimeBudgetCheckEvent__e to trigger the threshold evaluation logic.

Real-time threshold path (requirement 21):

Harvest webhook is configured to fire on time_entry.created and time_entry.updated events.
Webhook POSTs to a MuleSoft HTTP listener endpoint.
MuleSoft enriches the payload with the Salesforce project record ID using the Harvest project code as a lookup key.
MuleSoft fires the TimeBudgetCheckEvent__e Platform Event immediately.
A Salesforce Flow subscribed to the Platform Event recalculates total consumed hours on the project and sends an alert notification if the 80% or 100% threshold is crossed.

Error handling (requirement 23): MuleSoft Object Store holds a dead-letter queue for failed upsert batches. If Harvest is unreachable, the scheduled flow logs the failure and retries at the next scheduled interval. On reconnection, the updated_since filter catches all entries missed during the outage. The Harvest_Entry_Id__c external ID on Time_Entry__c guarantees idempotency; replaying a batch does not create duplicates.

OWD Settings

Object	OWD Setting	Rationale
Account	Private	Client isolation; req 7
Project__c	Private	Client project isolation; req 7
Project_Assignment__c	Private	Staffing data not visible broadly; req 10
Resource_Profile__c	Public Read Only	VP Delivery needs org-wide visibility; req 15
Skill__c	Controlled by Parent	Inherits from Resource_Profile__c
Certification__c	Controlled by Parent	Inherits from Resource_Profile__c
Time_Entry__c	Controlled by Parent	Master-Detail to Project__c; inherits Project__c sharing automatically
Opportunity	Private	Sales pipeline isolated from delivery; req 10

Role Hierarchy

Managing Partner
└── VP of Delivery
    ├── Practice Lead (San Francisco)
    │   └── Project Manager (SF)
    │       └── Consultant (SF)
    ├── Practice Lead (Chicago)
    │   └── Project Manager (Chicago)
    │       └── Consultant (Chicago)
    └── Practice Lead (Austin)
        └── Project Manager (Austin)
            └── Consultant (Austin)
CFO (peer to VP of Delivery, reports to Managing Partner)
Sales Director
└── Account Executive

Senior roles (Managing Partner, VP of Delivery, CFO) inherit all records from their reporting chain automatically, satisfying requirement 9. No manual sharing or admin-granted system administrator access is needed.

Account sharing rule: Share all Accounts where Office__c = "San Francisco" with the SF Practice Lead role (and downward). Repeat for Chicago and Austin. This gives practice leads full client visibility within their office without opening records to all users.

Project sharing rule: Share Project__c records with the assigned project manager role level and above using a criteria-based rule on Project_Manager__c office field.

When a Project_Assignment__c record is created (consultant added to a project), an Apex after-insert trigger creates a Project__Share record granting the consultant Read access to the parent Project__c and its child Time Entries. When Assignment_End__c passes (detected by a scheduled Flow running nightly), the share record is deleted; satisfying requirement 12’s 24-hour revocation window. A scheduled Flow handles this daily rather than relying on the trigger’s delete event, because off-boarding scenarios may not always result in an immediate deletion of the assignment record.

NDA Documents and File Access (Requirement 11)

Salesforce Files (ContentDocument / ContentDocumentLink) respect the sharing of the linked parent record. With OWD Private on Project__c, only users with explicit access to the parent project can retrieve its linked files. This is standard Salesforce behavior and does not require custom code. However, confirm that the Salesforce org does not have “Anyone can see file” sharing turned on in Content Settings, and that the Files content delivery setting is restricted to authenticated users.

Sales Team Visibility Boundary (Requirement 10)

Sales users have no permission set granting access to Project__c, Project_Assignment__c, Time_Entry__c, or Resource_Profile__c. The Pinnacle Sales Lightning App navigation excludes these objects. Sharing rules do not apply unless the object’s OWD grants read access in the first place; Private OWD is the enforcement backstop.

Migration Strategy

Phase 1: CRM Data Migration

Source: Existing Salesforce org (Professional edition, 25 licenses) and any supplemental spreadsheets.

Approach:

Deduplicate Accounts and Contacts in the source using Salesforce’s built-in duplicate management before any migration tooling runs. This is a data quality prerequisite, not a tooling problem.
Export cleaned Accounts, Contacts, Opportunities (open pipeline only) using Data Export or a simple Data Loader extract.
Load into Enterprise org using Data Loader with Insert (not Upsert) since records are moving to a new org; all IDs change. Use an external ID field (Legacy_SF_Id__c) to preserve the mapping for relationship resolution.
Validate counts and spot-check critical records before decommissioning the Professional org.

Volume: Manageable. 35 accounts, several hundred contacts at most. No large data volume concerns.

Phase 2: Resource Profile and Skills Loading

HR provides a BambooHR export of employee records, skills, and certifications. A Data Loader import creates Resource_Profile__c, Skill__c, and Certification__c records. Map BambooHR employee IDs to Salesforce User records using email address as the match key.

Reporting Approach

Utilization Dashboard (Requirement 15)

A Salesforce report of type Resource_Profile__c with Project_Assignment__c calculates:

Current utilization as a rollup of active assignment hours against weekly availability
Grouped by office for the VP of Delivery’s office-level view
Filtered by Is_Active__c = true on the assignment for current-state accuracy

For the 30-day and 60-day availability view, a scheduled Flow updates a Next_30_Day_Available_Hours__c field on Resource_Profile__c nightly based on the assignment end dates. The report surfaces this pre-calculated field rather than trying to perform date math inside the report engine.

Project Health and Budget Report (Requirement 22)

A Salesforce report of type Project__c with Time_Entry__c groups by Project, Billing Period, and Consultant to produce total approved hours per billing period. Report is filtered to the current billing period by default. Finance runs this directly from Salesforce without exporting; the report covers the “total approved hours by consultant, by project, and by billing period” requirement with standard joined report or matrix report functionality.

Alert Automation (Requirements 16, 17)

Budget threshold alerts (req 16): A Flow subscribed to the TimeBudgetCheckEvent__e Platform Event checks SUM(Time_Entry__c.Hours_Logged__c) against Project__c.Contracted_Hours__c. Sends in-app notification + email to the Project Manager when 80% and 100% thresholds are crossed. A checkbox Alert_80_Sent__c on Project__c prevents repeated alerts.

Certification expiry alerts (req 17): A scheduled Flow runs daily and queries Certification__c records where Expiration_Date__c <= TODAY() + 60 and Expiry_Alert_Sent__c = false. Sends email notification to the consultant and their direct manager (resolved via the User’s ManagerId field). Sets Expiry_Alert_Sent__c = true.

Requirements Addressed

#	Requirement	Solution Component
1	Single org, three offices	Enterprise edition upgrade, single org retained
2	Business unit separation	Role hierarchy with office branches; Permission Set Groups
3	Edition and licensing for full scope	Enterprise edition; Sales Cloud (~20) + Salesforce Platform (~180) licenses
4	Differentiated UX for delivery vs sales	Two Lightning Apps: Pinnacle Sales, Pinnacle Delivery
5	Entra ID SSO, no local passwords	SAML 2.0 via My Domain; login policy blocks non-SSO
6	Phased rollout support	Phased permission set activation; Phase 1 CRM, Phase 2 projects, Phase 3 integration
7	Client data isolation at record level	OWD Private on Project__c and related objects; Apex managed sharing
8	Role hierarchy matches org reporting structure	Hierarchy modeled: Consultant → PM → Practice Lead → VP Delivery → Managing Partner
9	Executive cross-account visibility without sysadmin	Senior roles at top of hierarchy inherit all records below them
10	Sales cannot see delivery/project/financial data	Sales has no object-level permissions on project objects; OWD Private backstop
11	NDA attachments accessible only to record-sharers	Salesforce Files + Private OWD on parent; content delivery restricted
12	Access revocation within 24h of roll-off	Scheduled Flow nightly deletes Project__Share when Assignment_End passes
13	Project record with required fields	Project__c custom object with all required fields + Lookup to Account
14	Consultant resource profile with skills and availability	Resource_Profile__c + Skill__c + Certification__c child objects
15	Real-time staffing report for VP Delivery	Report on Resource_Profile__c + Assignment; pre-calculated availability fields
16	PM alerts at 80% and 100% budget consumption	Platform Event + Flow; checkbox prevents repeat alerts
17	Certification expiry alert 60 days prior	Scheduled Flow daily; notifies consultant and manager via User.ManagerId
18	Search consultants by skill, cert, office, availability	Report with filters; or SOSL search in a custom LWC search component
19	Staffing plan on Opportunity converts to Project on Closed Won	Flow on Opportunity stage change; maps staffing plan fields to Project__c
20	Harvest sync at least hourly	MuleSoft scheduled flow every 60 min; upsert on external ID
21	Real-time threshold alert from Harvest	Harvest webhook → MuleSoft → Platform Event → Flow
22	Billing summary report in Salesforce without export	Matrix report: Project__c with Time_Entry__c grouped by billing period and consultant
23	Graceful sync failure with no data loss, no duplicates	MuleSoft dead-letter queue + Object Store; `Harvest_Entry_Id__c` external ID for idempotency

Risk Assessment

Risk 1: Platform license users and custom object access Salesforce Platform licenses include read access to Accounts and Contacts but exclude Opportunities, Forecasts, and other Sales Cloud objects. They do provide full access to custom objects. If the data model inadvertently places project records as children of standard objects in a way that requires Sales Cloud object permissions, Platform-licensed consultants will encounter access errors. Mitigation: complete the object permission matrix before Phase 1 development begins and validate with a representative test user.

Risk 2: Budget overrun in the $350K envelope The “One Platform” scope (Enterprise org upgrade, licensing for 200 users, MuleSoft integration, custom objects, and three phased rollouts) is ambitious for $350K. MuleSoft Anypoint is the most cost-variable element. Mitigation: if budget pressure appears, evaluate whether a direct Apex-based Harvest integration (no middleware) meets requirement 23 acceptably. A direct callout with a custom retry object can approximate the middleware queue at lower license cost.

Risk 3: BambooHR skill data quality The scenario explicitly notes that BambooHR is “rarely updated in practice.” A Phase 2 migration of stale skills data into Salesforce will produce an inaccurate resource directory from day one, undermining Sandra Chen’s stated goal. Mitigation: require HR to run a data cleanse of BambooHR records (or collect updated data via a Form/Survey) before the Phase 2 import rather than migrating the existing state as-is.

Risk 4: Apex sharing complexity at scale Apex managed sharing adds implementation and maintenance complexity compared to declarative sharing rules. If the sharing logic needs to handle team reassignments, project merges, or multi-office consultant placements, the trigger logic grows. Mitigation: document all sharing scenarios before writing the trigger. Use a dedicated sharing recalculation batch job that can be re-run if sharing records fall out of sync, rather than relying solely on real-time triggers.

Domain Scoring Notes

System Architecture Domain: Likely Judge Probes

Edition choice justification: Be ready to explain precisely why Professional edition is insufficient. The critical missing features are: Apex (no programmatic sharing without it), Flow Builder for advanced automation, custom REST API callouts (needed for Harvest sync), and the granular sharing rules and permission set groups needed for differentiated UX. PE does support basic permission sets, but not at the depth this solution requires. A vague answer of “we need more features” will not satisfy a board judge.

Single org vs multi-org: The scenario instructs single org, but a judge may challenge whether client data isolation requirements conflict with this. The correct response is that OWD Private with Apex managed sharing achieves record-level isolation within a single org. Multi-org is not warranted here and would add administrative overhead far exceeding the isolation benefit for a 200-user firm.

Phased rollout feasibility: Judges will probe whether the 6-month Phase 1 deadline is realistic given the enterprise edition upgrade, data migration, and SSO configuration needed. The answer is yes; an in-place upgrade requires Salesforce to approve the license change, but no data migration is involved for the upgrade itself. Data cleanse and migration of the 4-year CRM history is the real risk.

Security Domain: Likely Judge Probes

24-hour access revocation (requirement 12): Judges may ask whether a scheduled nightly Flow truly meets the “within 24 hours” requirement. Yes; if the Flow runs at midnight and the assignment end date is today, revocation happens before the 24-hour window closes. The only gap is intraday roll-offs where the consultant is removed immediately. For those cases, PM can manually inactivate the assignment record, which the Flow will then process, or a record-triggered Flow on Assignment_End__c update can handle immediate revocation.

NDA files (requirement 11): Judges will often ask whether standard Salesforce content sharing is sufficient or whether a custom security layer is needed. The answer: standard Salesforce Files sharing is sufficient when OWD on the parent record is Private, because ContentDocumentLink inherits the parent record’s visibility. The trap to avoid is assuming that all files in Salesforce are visible org-wide; they are not, as long as you do not enable public links or “anyone with the link” sharing.

What Would Fail

Anti-pattern 1: Master-Detail to Account on Project__c (or Controlled by Parent OWD) Making Project__c a Master-Detail child of Account, or setting its OWD to Controlled by Parent, causes Project__c to inherit Account’s sharing model entirely. This means Project__c cannot have its own OWD, cannot have its own sharing rules, and crucially cannot use Apex managed sharing (no Project__Share table exists for Master-Detail objects). Any sharing rule that opens Account visibility (e.g., for the sales team) pulls project data along with it, violating requirement 7. The fix is a Lookup relationship to Account, which lets Project__c have OWD Private and a fully independent sharing model with Apex managed sharing via the Project__Share table.

Anti-pattern 2: All users on full Salesforce licenses Provisioning all 200 users with full Sales Cloud licenses would likely blow the $350K budget purely on licensing. Salesforce Platform licenses at ~$25/user/month vs full CRM licenses at $75-150/user/month is a meaningful cost difference across 140 billable consultants and ~40 delivery/HR/finance staff who only need custom object access.

Anti-pattern 3: Direct Apex callouts for Harvest sync without a queue An Apex scheduled job that calls Harvest directly handles the happy path but fails requirement 23. When Harvest is unavailable, a direct callout throws a callout exception. Without a persistent queue outside of Salesforce’s Apex retry mechanism, failed entries are lost or create duplicate processing if the scheduler fires again before the previous attempt’s failure is logged. Middleware with a durable queue is the right pattern when no-data-loss + no-duplicate guarantees are required.

Scoring Rubric

Criterion	Weight	What a Strong Answer Includes
Org strategy and licensing	20%	Enterprise edition justification, license type differentiation, in-place upgrade rationale, and cost awareness
Client data isolation	25%	OWD Private on project objects, Apex managed sharing on assignment, NDA file handling, sales/delivery boundary
Role hierarchy and access design	20%	Full hierarchy modeled, executive cross-account access via hierarchy (not sysadmin), 24h revocation mechanism named
Integration architecture	20%	Middleware rationale, hourly scheduled + real-time webhook paths, idempotent upsert, graceful failure queue
Risk awareness and constraints	15%	At least 3 concrete risks, budget acknowledgment, BambooHR data quality flag, Platform license limitation awareness

Self-Assessment Checklist

Did I identify that Professional edition is insufficient and name at least two specific missing features?
Did I set OWD to Private on Project__c rather than Controlled by Parent or Public?
Did I design the role hierarchy with all five levels (Consultant, PM, Practice Lead, VP Delivery, Managing Partner)?
Did I address how sales users are blocked from seeing project/delivery data; not just at the UI level but at the object permission and OWD level?
Did I propose an idempotent mechanism (external ID) for the Harvest sync to prevent duplicates on retry?
Did I address the 24-hour access revocation with a named mechanism (scheduled Flow, batch job, or record-triggered Flow on Assignment_End update)?
Did I flag the BambooHR data quality issue as a Phase 2 risk rather than treating a data migration as purely mechanical?
Did I cover all 23 numbered requirements; even the ones that require only a brief answer?

Q&A Prep

Q: Why not keep the Professional edition org and use workarounds? A: Professional edition does not support Apex (required for programmatic sharing), Flow Builder for advanced automation, or custom REST API callouts (required for the Harvest integration). It also lacks the permission set groups and granular sharing rules needed to differentiate delivery from sales users; PE has basic permission sets but not at the depth Enterprise provides. These are not gaps you can work around; they are foundational to requirements 7 through 12.

Q: Why upgrade in-place rather than starting a new Enterprise org? A: The existing org has 4 years of account and contact history used by the sales team. Migrating that data introduces risk and data quality overhead that can be avoided entirely by upgrading the license. Salesforce supports in-place edition upgrades. The only action required is a contract amendment with Salesforce.

Q: Why MuleSoft instead of a direct Apex callout to Harvest? A: Requirement 23 demands no data loss and no duplicates even when Harvest is unavailable. A durable queue outside Salesforce is the cleanest way to guarantee this. MuleSoft’s Object Store provides that queue. A direct Apex callout can be retried, but Salesforce’s retry mechanism for callout failures is not a persistent queue; if the org restarts or the batch job fails before the retry is attempted, entries can be lost. If budget makes MuleSoft prohibitive, the alternative is a lightweight integration middleware (e.g., a Node.js service on cloud infrastructure) with a database-backed queue, not a pure Apex solution.

Q: A board member asks: could a consultant from one client engagement ever see another client’s data under your design? A: No. OWD Private on Project__c means a user can only see a project record if they are the record owner, in a role above the owner, or explicitly shared via a sharing record. Sharing records are created only when a consultant is added to a Project_Assignment__c record for that specific project. No sharing rule or other mechanism opens project records broadly. A consultant on the Morgan Stanley project has a sharing record for that project and no others.

Q: How do you handle a consultant who is on two projects simultaneously? A: Each Project_Assignment__c record creates a separate sharing record. The consultant gets access to both parent Project__c records while both assignments are active. When either Assignment_End__c date passes, the sharing record for that project is removed while the other remains.

Q: The sales team needs to see the staffing plan attached to their opportunity. How does that work without giving them access to Project__c? A: The staffing plan lives on the Opportunity as a child object or as an Opportunity attachment, not on Project__c. It is only promoted to a Project__c record when the deal closes. Before close, sales users access the staffing plan through the Opportunity record they already have access to. The conversion Flow creates the Project__c record and assigns it to the delivery team, at which point the sales user no longer needs access to the project record.

Q: How does an executive (Managing Partner, VP of Delivery, CFO) get cross-account visibility without sysadmin? A: The role hierarchy places these users at the top of the hierarchy. In Salesforce, a user’s role can see all records owned by users in roles below them in the hierarchy. Because every project manager and consultant is below these executives in the role hierarchy, the executives automatically see all project records owned by anyone in the delivery chain. No manual sharing or sysadmin privileges are needed.

Q: What happens if a project manager leaves the company mid-engagement? A: The PM’s User record should be deactivated, not deleted. Deactivating preserves record ownership and history. The project record’s Project_Manager__c lookup should be updated to the new PM, which the admin can do via a simple record edit. If the Project__c OWD is Private and the record is owner-based, deactivating the owner without reassigning could temporarily restrict access; this is the operational risk to flag and address with a run-as reassignment policy.

Q: Should we integrate BambooHR into Salesforce in Phase 2? A: The constraint explicitly excludes BambooHR integration. Phase 2 loads data from a BambooHR export. The architectural note is that BambooHR should remain the system of record, and Salesforce should hold a copy for search and staffing purposes. Future phases should consider a one-way sync from BambooHR to Salesforce for certifications and skills. Two-way sync is risky because HR professionals do not typically work in Salesforce.

Q: The 60-day certification alert fires once. What if someone ignores it? A: The current design fires once when the 60-day window opens and sets Expiry_Alert_Sent__c = true. An improvement would be a second alert at 30 days; cleared by a separate checkbox field Expiry_Alert_30_Sent__c. This is a quick iterative enhancement for Phase 2 but is not required by the scenario.

Q: How do you prevent the Harvest sync from creating Time_Entry__c records for projects that no longer exist in Salesforce? A: The MuleSoft upsert uses the Salesforce project record ID as a foreign key on the Time_Entry__c. If the project ID does not match an active Project__c, the upsert fails for that record and the entry lands in MuleSoft’s error queue for manual review. This is appropriate behavior; a time entry against an unknown project is a data quality issue that needs human resolution, not silent discard.

Q: Is the nightly access revocation truly automatic? What if the scheduled Flow fails? A: The scheduled Flow deletes sharing records for assignments where Assignment_End__c < TODAY(). If the Flow fails on a given night, it retries at the next scheduled run. The worst case is a 24-to-48 hour delay in revocation, which technically violates the 24-hour window. Mitigation: configure Flow error notifications to alert the admin team so they can manually trigger the Flow if failures are detected. For higher assurance, this logic can move to an Apex scheduled batch class, which has better error logging and retry mechanics than scheduled Flows.

Presentation Notes

Opening frame for the board: Lead with the client confidentiality guarantee. Marcus Webb’s quote makes clear that this is the non-negotiable foundation. Establish that OWD Private on project objects is the starting position, not an afterthought, and explain briefly that all other sharing opens access selectively from that locked-down baseline. This reframes the security model as trust by design rather than access by default.

Sequence of topics: Recommend presenting in this order for a smooth narrative: (1) org strategy and licensing decision, (2) role hierarchy diagram, (3) sharing model walkthrough, (4) data model sketch, (5) integration architecture. Judges typically probe security hardest in this type of scenario, so front-loading the sharing model narrative before integration positions you well for the Q&A that follows.

Anticipate the challenge on the 24-hour revocation: Boards will often probe automated revocation. Have a crisp one-sentence answer ready: “A scheduled Flow runs nightly, checks all Project Assignments where the end date has passed, and deletes the corresponding project sharing records; no admin action required.” Then offer the enhancement for immediate revocation if the assignment record is updated in real time.

Licensing cost signal: If asked about budget fit, acknowledge that licensing 200 users on Enterprise edition with a MuleSoft integration is the largest budget line item and needs to be validated in week one. Showing cost awareness without having exact figures demonstrates architectural maturity; you are not expected to quote Salesforce pricing to the dollar, but you should flag it as a first-priority assumption to verify.

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.