Scope: Define a prescriptive yet flexible model to convert Salesforce Opportunities/Quotes/Orders/Contracts into services delivery projects in Rocketlane; provision projects pre-close for capacity forecasting; standardize template routing, soft→hard allocations, and health/milestone tracking; surface financials (time, cost, margin, recognized revenue) back to Salesforce; and handle bundles, retainers, and amendments through a 1:1 Salesforce Project ↔ Rocketlane Project mapping.

Why this article

Professional Services teams need a reliable way to turn sales intent into delivery plans. This article documents Rocketlane’s opinionated but flexible approach to mapping Salesforce selling objects to Rocketlane Projects. Our recommended pattern creates a one‑to‑one relationship between a Salesforce Project record (a custom object we’ll call Project__c) and a Rocketlane Project. The 1:1 model keeps ownership clear, updates deterministic, and reporting sane—even as opportunities evolve, bundles shift, or dates move.

We will walk through the end‑to‑end process in plain language: how records are created, when projects are provisioned (including before a deal is closed‑won), how we keep data in sync, and how we cope with amendments, bundles, retainers, and orders/contracts.

The core idea: a Project per deliverable

In Salesforce, the Opportunity remains the commercial parent. Beneath it, we create one Project__c record for each deliverable you want to manage separately in Rocketlane. Sometimes that means one project for each Opportunity Line Item; sometimes it means one project that represents a bundled platform rollout; sometimes it’s a retainer or bucket of hours. The guiding question is: will this workstream have its own plan, dates, staffing, budget, health, and outcomes? If yes, give it its own Project__c and therefore its own Rocketlane Project.

This simple rule pays off throughout the lifecycle. It lets PS leaders forecast credibly during the sales cycle, it allows resource managers to soft‑book people early and firm up as confidence rises, and it gives Finance clean hooks for revenue and cost telemetry once delivery starts. It also makes bi‑directional syncing predictable: there is always exactly one place in Salesforce that represents the corresponding project in Rocketlane.

One Opportunity to Many Projects:

Why we recommend the 1:1 Salesforce Project ↔ Rocketlane Project model

A one-to-one relationship between a Salesforce Project record (Project__c) and a Rocketlane Project is the most reliable and scalable way to run services (PS/MS) from CRM through PSA.

Long‑term scalability

• As your catalog grows, each new deliverable simply becomes one more Project__c and one more Rocketlane Project—no re‑architecture or brittle filters. 
• Bundles stay flexible: keep them together as one project (phases/components inside Rocketlane), or split into multiple projects when timelines/teams diverge.

Deterministic sync & governance

• Every update (dates, owners, scope attributes) has exactly one target on each side, which makes upserts idempotent and retries safe.
• Auditability is clean: one correlation ID per project across systems. No reconciliation of “which child updated which parent?”

Cleaner reporting & accountability

• Delivery telemetry (health, milestones, hours, burn, rev/margin) rolls up from Project → Opportunity/Order → Account in Salesforce, and stays consistent with Rocketlane.
• Dashboards are easier to trust because scope, dates, staffing, and results live at the same granularity.

Why not 1:many or many:1?

1. Field sync becomes ambiguous (which child wins?), updates collide, and idempotency breaks. You end up with drift, duplicate projects, and manual cleanup.
2. Milestones and revenue events are especially error‑prone when multiple Salesforce records point to one Rocketlane project (or vice versa); acceptance, dates, and amounts cannot be deterministically mapped.

Where the projects come from

Most organizations derive Project__c from data the seller already maintains:

• From Opportunity Line Items (OLIs) when you sell implementation SKUs or services.
• From Quote Line Items (QLIs) when you use CPQ and quotes are the source of truth.
• From Order Items or Contracts when projects are provisioned only after booking.

A lightweight record‑triggered Flow examines those lines and decides which ones warrant a project. Non‑delivery items (e.g., licenses that don’t require PS) are ignored; delivery lines (implementations, consulting packages, hours buckets) generate Project__c records. If several products are tightly coupled in delivery, the Flow can create one Project__c for the bundle and record the components on a related list or field. If they will move on different timelines or be staffed by different teams, create separate Project__c records.

Flowchart (deal-to-project):

State machine (forecast lifecycle):

Forecasting before Close‑Won

Often, PS needs to plan before revenue is booked. Rocketlane supports this nativel. When an Opportunity reaches a defined stage (e.g., Proposal or Negotiation) or crosses a probability threshold (say 50%), Salesforce automatically creates Forecasted Project__c records and, if you choose, provisions Tentative projects in Rocketlane. These Tentative projects carry a clear state that keeps them out of live delivery metrics while still appearing in capacity and pipeline views. Resource managers can place soft allocations (via placeholders by role/skill) and later convert them to hard allocations once commitment rises.

As the Opportunity advances—perhaps at 80% probability—the project’s forecast status moves to Reserved. At Closed‑Won, the status becomes Booked and the Rocketlane project switches from Tentative to Active without losing history or allocations. If the deal slips or is lost, Salesforce flows send a cancellation/update so Rocketlane frees up capacity and keeps an audit trail. Throughout, the 1:1 mapping ensures that a date change or ownership change in Salesforce updates the correct single project in Rocketlane.

Capacity dashboard showing Soft and Hard allocations of projects by month:

How the integration behaves (creation and updates)

The integration has two jobs: create/update projects in Rocketlane and sync delivery signals (fields) back to Salesforce. Creation is always idempotent—Salesforce and Rocketlane establish a unique 1:1 mapping between record IDs and the integration updates the Rocketlane project via this unique mapping. This prevents duplicates and makes retries safe.

Updates are bi-directional. When dates, owners, or attributes change in Salesforce, only those fields are pushed to Rocketlane. When delivery progresses in Rocketlane—milestones complete, phases advance, hours/budget burn, or health changes—those signals are written back to Project__c so that GTM stakeholders can report without logging into a delivery tool. For complex enterprises (multi‑org, cross‑cloud lookups, specialized transformations), Rocketlane’s embedded iPaaS sits in the middle to orchestrate routing, handles advanced scripting, and provide dead‑letter queues and audit logs. For many customers, the native Salesforce integration is sufficient, robust, and simpler to operate.

Salesforce Automation Worklow(s) (Create Project):

Rocketlane ↔ Salesforce field mapping UI:

Naming, routing, and templates

Consistency matters for rollout. We recommend a predictable naming scheme such as {Account} – {SKU/Bundle} – {Region}. A routing condition—typically some combination of SKU, Product Family, Region, and Segment—determines the Rocketlane template to use. Maintain this routing map in Salesforce as fields so admins can evolve it without code. Validation rules should block project creation until essential attributes exist (owner, key dates, region, routing key), which keeps bad data from reaching Rocketlane.

Variations we support (and when to use them)

Some customers will create one project for a bundle when delivery is inherently integrated (e.g., a platform rollout that always ships as a single plan). Others will create separate projects per product when staffing or timelines diverge. Both are fine—what matters is that each Rocketlane project has exactly one Project__c peer.

For hours buckets/retainers, create a Project__c that represents the bucket (e.g., “Advisory – 100h”). Rocketlane will track time budgets and burn‑down, and you can sync consumption back into Salesforce for commercial oversight. For amendments and upsells, create a fresh Project__c linked to the prior one via a field like Upsell__c. Depending on your governance, you may extend the existing Rocketlane project with a new phase/scope or create a new project; the 1:1 rule still holds—each Project__c maps to exactly one Rocketlane project.

When projects are created post‑booking, some organizations prefer Orders or Contracts as the master record. The same child pattern applies: the order or contract anchors the commercial truth; each deliverable spawns a Project__c, which then provisions a Rocketlane project.

A day in the life (Sample scenario)

Imagine an Opportunity at Proposal with three QLIs: Core Platform, Data Migration (Phase 2), and Advisory 100h. Probability hits 60%, so Salesforce creates three Project__c records, marks them Forecasted, and—per policy—provisions three Tentative projects in Rocketlane. Resource management assigns soft placeholders for a PM, a migration specialist, and a consultant pool. Two weeks later, negotiations move Data Migration up into phase 1; the dates are updated on that single Project__c, and Rocketlane receives just that delta.

At Closed‑Won, the three projects flip to Booked. The PM converts soft to hard allocations and kicks off the template playbooks. Delivery progresses: the migration project completes its first milestone; Rocketlane posts the milestone date and updated health back to its Project__c. Finance pulls recognized revenue from Rocketlane’s telemetry to power managerial reporting. Mid‑delivery, Sales sells an additional 40h of advisory—Salesforce creates a new Project__c linked to the original retainer; Rocketlane provisions a new scoped project, keeping forecasting and attribution clean. All of this happens without anyone reconciling spreadsheets because every workstream has a single source of truth in both systems.

Milestones & financial deliverables

Milestones are where delivery proof and commercial events meet.

What to model

• In Salesforce, use a child object (e.g., Project_Milestone__c) under Project__c with fields like:

  Name, Type (Delivery/Financial), Planned Date, Target Date, Acceptance Date, Status, Amount (if financial), Recognized Amount (optional), Rocketlane_Milestone_ID__c.

• In Rocketlane, use Milestones (and phases/tasks) to drive execution; expose status, due/actual dates, acceptance, and any financial tags needed for reporting.

How it flows

1. Creation: Milestones originate from the Rocketlane template or from Salesforce (via the quote/order/SoW).
2. Sync to Rocketlane: If milestones are defined in Salesforce (e.g., “Design Sign-off,” “Go-Live,” “UAT Complete”), push them when the project is provisioned so the plan matches the contract.
3. Execution & acceptance: Rocketlane updates status and dates; when a milestone is marked Accepted, push acceptance back to Project_Milestone__c.
4. Financial linkage:
   • Milestone-based billing/recognition: Tie the Amount on the milestone to billing events and (if policy requires) recognized revenue.
   • % Complete recognition: Keep milestones for schedule/health while recognition is computed from hours/EAC and synced to Project__c.
5. Roll-ups & dashboards: Surface “Milestones due/accepted this period,” “Revenue attached to accepted milestones,” and “Risked milestones” at the Project__c level and roll up to Opportunity/Account.

Field sync (what we actually sync and why)

Every Project__c carries a small set of fields that make synchronization predictable. Identity and linkage fields—Project__c__ID, Rocketlane_Project_ID__c, and lookups to Account and Opportunity—anchor the relationship and support upserts.

Commercial context such as SKU/Product Code, Quantity/Term, and Amount/ARR ensures the right template, the right entitlement windows, and meaningful financial rollups. Operational attributes—Region, Practice, Project Owner, and any other attribute—drive routing to the correct Rocketlane template and playbook. Forecasting attributes—Forecast Status (Forecasted, Reserved, Booked), Confidence, and Target Start/End—feed capacity planning and make pre‑close projects first‑class citizens in PS planning.

On the way back from Rocketlane, we capture Project Health and notes, milestone statuses and dates, phase progress, task counts, hours burned versus remaining, and, when modeled, recognized revenue and margins. Writing these to the Project__c keeps GTM dashboards truthful without exposing delivery users to Salesforce internals—or vice versa.

Error handling and governance that scale

Production integrations fail gracefully. Updates use the unique 1:1 mapping between the platforms so that retries never duplicate projects. The embedded iPaaS (when used) provides retries with exponential backoff, a dead‑letter queue for stubborn records, and correlation IDs so an admin can trace a single project’s journey across systems. Validation rules in Salesforce keep incomplete data from provisioning half‑formed projects, and a small monitoring dashboard tracks creations, updates, and failures.

Frequently asked questions

1. What happens when Close Dates move? Salesforce pushes the new dates to the corresponding Project__c; the integration adjusts the Rocketlane project’s tentative or booked dates. Because the relationship is 1:1, there’s no ambiguity about which project to update.
2. Can we keep one project for a multi‑SKU bundle? Yes—if delivery will move as one plan with one team, create a single Project__c and reflect the components inside Rocketlane using multiple budgets, phases, milestones, and tasks. If components will diverge in schedule or staffing, split them into separate projects from the start.
3. How do we avoid duplicate projects? Every update to Rocketlane uses the unique 1:1 mapping between records. If a network hiccup occurs mid‑provisioning, a retry simply resumes without creating a second project.
4. Can we recognize revenue from Rocketlane? Many customers do. Rocketlane can provide recognized revenue and cost/margin telemetry back to Salesforce/ERP—either onto Project__c or a finance object—so long as your financial policy is modeled.
5. We prefer Orders to Opportunities. Is the model different? The commercial parent changes, but the pattern does not. Orders (or Contracts) remain the master; each deliverable still becomes a Project__c that maps 1:1 to a Rocketlane project.

Implementation checklist

• Before you turn this on, make sure you have a clean Project__c with the identity, routing, and forecasting fields described above.
• Build a record‑triggered Flow that runs on Opportunity (and, if you use CPQ heavily, on Quote) to evaluate line items and create the right number of projects.
• Configure the Rocketlane integration with automation rules with conditions to automatically create projects and map the core fields in both directions.
• If you operate at a complex scale or across multiple orgs, place the embedded iPaaS in the middle and enable retries, DLQ, and audit.
• Finally, pilot with a handful of real deals—single SKU, bundled rollout, a retainer—so PS leadership can validate forecasting views, resource managers can test soft→hard allocation transitions, and Finance can confirm the telemetry they need appears on the Project__c and rolls up correctly.