Pigment integrations connect an EPM model to the operational systems that hold the inputs finance needs, such as CRM, ERP, data warehouse, and workforce data. The hard part is not moving records. It is deciding what each record means, which system owns it, when it should refresh, and how finance will validate the result.
Get in touch about your Pigment integration plan
For a VP of Finance or FP&A leader, that distinction matters. A model can be technically connected and still produce an unreliable forecast if the Salesforce pipeline is mapped to the wrong period. The warehouse data may have a different grain than the plan. Workforce changes may also arrive without an accountable owner. Amvent's Pigment implementation services treat integration and data validation as a defined workstream rather than a final connector task.
This guide focuses on the decisions behind the most common connections. It explains how to separate source-system responsibility from planning logic, how to create useful validation controls, and how to scope the work with an implementation partner.
Why are Pigment integrations often the hardest part of an EPM implementation?
Pigment integrations are often the hardest implementation work because they sit between different operating definitions. Sales, finance, HR. And IT may use the same words while storing different versions of the underlying data. "Revenue," "headcount," "customer," and "month" can each have several valid definitions depending on the process.
An integration is usable when finance can answer four questions about every important input:
Who owns the source record? The responsible team can correct the data without guessing where the change belongs.
What is the required grain? The model receives detail that supports a decision, without importing unnecessary operational history.
When should the data refresh? The cadence matches the planning process and leaves room for review when a change affects the forecast.
How is the result reconciled? The team can compare counts, totals, dates, and mappings with the source system.
For example, an ERP may remain the source of record for actuals, while Pigment owns assumptions, allocations, scenarios, and approved plans. A CRM may provide opportunity and bookings data, but finance still needs to decide which stages, dates, currencies, and ownership fields belong in the revenue model.
Integration success is a finance control, not only a technical outcome
Technical connectivity proves that data can travel. It does not prove that the data is fit for planning. A refresh can complete successfully while excluding inactive records that should remain in a historical view, duplicating opportunities, or shifting a transaction into a different reporting period.
That is why integration scope should include mapping decisions, exception handling, reconciliation ownership, and sign-off criteria. Amvent's six-phase methodology assigns integrations and data validation to a dedicated phase before later testing and adoption activities depend on them. This structure helps the team resolve data questions while changes are still manageable.
The broader connected planning approach also depends on this foundation. Connecting more teams is valuable only when the shared model has definitions and controls that each team can trust.
How should Pigment and Salesforce share responsibility for financial planning?
Pigment and Salesforce should share responsibility by keeping commercial events in Salesforce and planning logic in Pigment. Salesforce can remain the source of record for accounts, opportunities, stages, close dates, ownership, and booked transactions. Pigment can use those inputs to build revenue forecasts, capacity plans, quota scenarios, and cross-functional financial models.
Start with the decisions the revenue plan must support
Do not begin by copying every Salesforce field into Pigment. Begin with the decisions finance and revenue operations need to make. Those may include whether pipeline can support a quarterly target, or how much capacity is needed by territory. They may also include whether hiring should change to support growth, or how a pushed close date affects the forecast.
Each decision determines the required dimensions and measures. A revenue model may need territory, segment, product, account, sales stage, currency, and period. It may not need every activity record or every historical field in the CRM. Limiting the integration to decision-relevant data makes the model easier to govern and keeps ownership clear.
Map Salesforce objects and fields to Pigment dimensions and metrics.
Define how opportunity stages translate into forecast categories.
Set rules for currency, close-date changes, inactive territories, and duplicate records.
Agree on whether bookings, billings, or recognized revenue is the relevant actual.
Assign an owner for exceptions shared by finance and sales operations.
Validate the commercial data before it drives a forecast
A practical validation routine can compare Salesforce record counts, pipeline values, stage totals, close-date ranges, currencies, and territory assignments with the values accepted in Pigment. The control should show whether a difference is expected, such as a deliberate filter, or needs investigation.
The goal is not to force Salesforce and Pigment to contain identical records. The goal is to make every difference explainable. A finance user should know whether Pigment is using open opportunities only, whether closed-won records are treated as actuals, and whether the forecast includes a management override.
Q: Should Pigment replace Salesforce for sales data?
A: No. In a well-designed model, Salesforce continues to manage CRM events and operational ownership, while Pigment turns approved inputs into planning scenarios, targets, allocations, and forecasts.
When should Snowflake feed Pigment as a planning source?
Snowflake is a strong upstream source for Pigment when it already consolidates reliable data from finance, product, customer, or operational systems. The warehouse can prepare a governed dataset, while Pigment provides the planning layer for assumptions, scenarios, allocations, targets, and approved plans.
Use the warehouse to prepare, not to replace, planning decisions
A warehouse often contains more detail than a planning model needs. Sending every event, table, and historical attribute into Pigment can make the model difficult to manage without improving the decisions it supports. A better approach is to define a planning-ready dataset with stable keys, consistent period logic, documented dimensions, and the measures required by the model.
The dataset design should answer:
Which system supplied the record and when it was last updated?
What business key joins the record to a Pigment dimension?
What time zone, fiscal calendar, and reporting period apply?
Which fields are actuals, assumptions, targets, or calculated outputs?
How are late-arriving records, restatements, and missing values handled?
Snowflake can remain the analytical system of record for detailed history and broad business intelligence. Pigment can then own the planning logic that finance users need to adjust, explain, and approve. That boundary prevents users from treating a raw analytical table as if it were an approved plan.
Build reconciliation into the Snowflake connection
Reconciliation should occur at the same grain used by the plan. If the model is organized by month, entity, department, and product, compare the accepted Snowflake dataset at those dimensions. If the source is more detailed, aggregate it in a controlled layer rather than relying on an unexplained transformation inside the model.
Document the treatment of nulls, deleted records, restated actuals, and dimension changes. Include a visible exception path so a failed refresh does not silently leave the forecast with stale inputs. Pigment's integration overview provides platform context, but the implementation still needs a design specific to the customer's data model and operating calendar.
Q: Is a Snowflake connection automatically the best integration pattern?
A: Not always. It is usually a strong pattern when Snowflake is already governed and consolidated. If source data is incomplete or poorly defined, fixing ownership and data quality first is more valuable than adding another connection.
How do BambooHR or Workday integrations support workforce planning?
BambooHR or Workday can provide workforce inputs for a Pigment headcount model, but the right pattern depends on the customer's system of record, data policy, and planning grain. The source system can hold employee and organizational facts. Pigment can use approved inputs to model headcount, compensation, hiring timing, vacancies, and workforce scenarios.
Separate employee facts from planning assumptions
Workforce integrations should distinguish between data that comes from HR and data that belongs to the plan. Employee identifiers, employment status, department, manager, location, job family, and current compensation may be source-system facts. Planned hires, vacancy timing, merit assumptions, position changes, and scenario choices may be planning inputs.
This separation prevents a planning adjustment from being overwritten by the next HR refresh. It also gives HR and finance a clear conversation about which changes should be made in BambooHR or Workday and which should be modeled in Pigment until approval.
Current workforce: employees and positions included in the baseline.
Organizational mapping: departments, cost centers, managers, entities, and locations aligned to the finance model.
Compensation logic: salary, benefits, bonus, currency, and effective-date treatment.
Future workforce: approved hires, vacancies, start dates, transfers, and role changes.
Scenario ownership: the team authorized to change assumptions and approve the resulting plan.
Plan for privacy and exception handling
Not every workforce model needs personally identifiable detail. Determine whether the planning decision requires employee-level records or whether an aggregated position view is sufficient. Limit the integration to the data needed for budgeting and workforce decisions, and define who can see sensitive fields.
Validation can compare headcount by department, location, job family, and status between the source system and Pigment. It should also flag employees without a mapped department, positions with missing effective dates, duplicate identifiers, and compensation records that do not match the expected currency or period.
Amvent's planning services cover workforce planning alongside financial and operational planning. That broader view is useful when headcount changes affect revenue capacity, operating expense, and the timing of a company-wide plan.
What does a governed Pigment integration architecture include?
A governed Pigment integration architecture makes data movement visible, repeatable, and accountable. It does not require every system to connect directly to every other system. It requires clear boundaries, stable mappings, and controls that show what happened when a refresh succeeded or failed.
Use a simple source-to-plan contract
For each connection, create a short contract that describes the source, destination, owner, grain, cadence, transformation, and validation rule. This can be maintained alongside the implementation documentation and reviewed when the model changes.
Design area | Decision to document | Example control |
|---|---|---|
Source ownership | Which system owns each fact? | ERP owns actuals; Pigment owns approved scenarios. |
Grain and keys | What detail and identifiers does the model require? | Monthly entity and department totals use stable mapped keys. |
Refresh cadence | When should new data be accepted? | Refresh aligns with the close and forecast calendar. |
Validation | What must pass before the refresh is accepted? | Counts, totals, dates, currencies, and unmapped values are checked. |
Exception ownership | Who investigates a failed control? | Finance owns planning variances; the source team owns source defects. |
Make failure behavior explicit
Every integration should define what happens when a refresh is late, incomplete, or inconsistent. The model may retain the last accepted dataset, mark the refresh as pending, or stop downstream processing until an owner approves an exception. The choice should be deliberate and visible to users.
Security and access should also be part of the design. NIST's zero trust architecture guidance reinforces the importance of explicit verification and least-privilege access in distributed environments. The specific control set will depend on the customer's architecture, but the principle is relevant whenever finance data crosses systems.
Finally, keep the model maintainable. A connection that only one person understands creates operational risk. Document field mappings, test cases, ownership, and escalation steps so the finance team can explain the model after go-live.
What should finance leaders ask an implementation partner about integration scoping?
Integration scoping should translate business requirements into a bounded implementation plan. Before selecting a partner or approving a statement of work. Finance leaders should ask questions that reveal whether the partner understands the operating process as well as the connector.
Which source systems will be authoritative for actuals, commercial inputs, workforce facts, and planning assumptions?
Which dimensions and measures will be integrated, and which will stay outside the first release?
What is the expected grain of each dataset, and how will keys be mapped?
How will the team handle duplicates, missing values, late records, restatements, and changed hierarchies?
Who owns each validation control during implementation and after go-live?
What is the refresh cadence, and how does it fit the close, forecast, and budget calendars?
What happens when a refresh fails or a source system changes a field?
How will finance users test and sign off on the integration before adoption?
Which data should be aggregated or staged before it reaches Pigment?
What documentation and managed support will remain after go-live?
The strongest answers connect integration decisions to planning outcomes. A partner should explain how a Salesforce field changes a revenue forecast. They should show how a workforce mapping affects an expense plan and how a Snowflake dataset will be reconciled during close. The discussion should also identify what is intentionally out of scope so the first release remains usable.
A practical scoping sequence is:
Define the planning decision: state what finance or an operating team needs to forecast, explain, or approve.
Identify the source: name the system of record and the owner for each required data domain.
Map the model: document the grain, dimensions, measures, keys, periods, and transformation rules.
Set the controls: agree on refresh timing, reconciliation checks, exception ownership, and sign-off criteria.
Bound the release: separate the first usable implementation from later integrations and enhancements.
Amvent combines Pigment specialization with a practitioner perspective from having led a large-scale migration as an end customer. Its implementation methodology is designed to move from model design through data validation, testing, adoption, and ongoing support. For organizations evaluating a connected planning program, that combination can make integration decisions more practical and more accountable.
Teams that want to compare their current data landscape with a workable Pigment integration scope can start with the Amvent team and delivery approach before defining the first planning use case.
Get in touch to discuss your integration scope
Frequently Asked Questions
What are Pigment integrations?
Pigment integrations connect Pigment to systems such as CRM, ERP, data warehouses, and workforce platforms. A useful integration defines ownership, mapping, grain, refresh timing, validation, and exception handling so the connected data can support an auditable plan.
Can Pigment integrate with Salesforce?
Yes, Salesforce data can support Pigment revenue planning when the implementation defines which CRM objects and fields matter. How stages and dates map to the model, and how pipeline, bookings, currencies, and territories are validated. Salesforce can remain the source of record for CRM events while Pigment owns planning scenarios and forecast logic.
Can Snowflake be used as a source for Pigment?
Yes. Snowflake can prepare and supply a governed planning dataset when it already consolidates reliable operational data. The team should still define the required grain, stable keys, period logic, refresh cadence, and reconciliation controls instead of copying every warehouse table into Pigment.
How do workforce integrations support a Pigment model?
BambooHR or Workday can provide current workforce facts such as employees, positions, departments, and compensation inputs. Pigment can then model hiring timing, vacancies, scenarios, and approved workforce assumptions. The integration should separate source-system facts from planning inputs and limit sensitive data to what the planning decision requires.
What should be included in an integration plan?
An integration plan should include source ownership, field and dimension mappings, required grain, refresh cadence, transformation rules, validation checks, exception handling, security considerations, testing responsibilities, and post-go-live support. It should also state what is out of scope for the first release.
Plan your Pigment integration with confidence
Reliable Pigment integrations give finance a connected planning model that can be explained, tested, and maintained. The right starting point is not a list of connectors. It is a clear agreement about the decisions the model must support and the controls that make each input trustworthy.
Get in touch with Amvent Consulting
