# HPI Pro — Full Knowledge Base

Website: https://hpi.pro/en
Language: English (en)
Hebrew edition: https://hpi.pro
Contact: https://hpi.pro/en/contact

> Salesforce and CRM consulting, architecture and implementation for companies and enterprises.

## Core pages
- https://hpi.pro/en/services
- https://hpi.pro/en/consulting-discovery
- https://hpi.pro/en/crm-architecture
- https://hpi.pro/en/salesforce-implementation
- https://hpi.pro/en/salesforce-health-check
- https://hpi.pro/en/salesforce-development-automation
- Salesforce CI/CD & DevOps: https://hpi.pro/en/salesforce-cicd-devops
- https://hpi.pro/en/agentforce-ai
- https://hpi.pro/en/integrations-data
- https://hpi.pro/en/support
- https://hpi.pro/en/salesforce-expert-staffing
- https://hpi.pro/en/solutions
- https://hpi.pro/en/methodology

- https://hpi.pro/en/about
- https://hpi.pro/en/insights
- https://hpi.pro/en/contact

---

# Knowledge Base

## Unpacking Salesforce Implementation Costs: Your Guide to a Responsible Estimate
URL: https://hpi.pro/en/insights/salesforce-implementation-cost
Salesforce implementation costs are driven by seven distinct factors, from licensing to integrations to hidden internal expenses. Approving a budget based on a single number often leads to budget overruns in the second round. Get the full picture before you commit.

## The Short Answer

There's no single answer to "how much does Salesforce implementation cost?" because it's a sum of seven distinct components, each behaving differently. Licensing is paid per user and edition level, while implementation services are based on the scope of work. Crucially, your team's internal, "hidden" hours are never included in a vendor's proposal. An organization that only budgets for what's on the contract will find itself over budget by the second month.

The correct way to approach this question is not to look for a single "Salesforce implementation price," but to build an estimation model that separates highly certain components (licensing) from those dependent on scope and complexity (implementation, integrations, migration). Those in an earlier selection phase can find additional background in [Choosing a Salesforce Implementation Company](/en/insights/choose-salesforce-implementation-company), while those already comparing proposals can use the article on [Salesforce RFP Guide](/en/insights/salesforce-rfp-guide).

## The Seven Cost Components

The cost of a Salesforce implementation isn't a single budget line item but rather seven distinct components, each priced differently and behaving uniquely over time:

1.  **Licensing** - Annual or monthly per-user cost, depending on the edition (Professional, Enterprise, Unlimited) and associated products like Sales Cloud, Service Cloud, or Data Cloud.
2.  **Implementation Services** - Work for discovery, configuration, custom development, and testing, typically priced hourly or as a Fixed Price based on a defined scope.
3.  **Integrations** - Connecting Salesforce with existing systems (ERP, payment processing, telephony, marketing tools); the cost depends on the number of systems and the complexity of data mapping between them.
4.  **Migration** - Cleaning, mapping, and transferring historical data from a previous system, often underestimated because original data quality isn't assessed upfront.
5.  **Training** - End-user and administrator training; an easily overlooked budget item that dictates actual adoption rates.
6.  **Ongoing Support** - Maintenance, bug fixes, minor changes, and version updates post-Go Live, typically under a separate agreement from the implementation.
7.  **Hidden Internal Costs** - Your organization's team hours: process owners, internal project manager, user acceptance testing (UAT), and change communication, which don't appear in the vendor's proposal but consume real resources.

## Pricing Factor Table

| Component | What Drives the Price | How to Reduce | Red Flag |
|---|---|---|---|
| Licensing | Number of users, edition, add-on products | Review actual usage before renewal; don't add "buffer" seats | Vendor recommends a higher edition without linking it to a specific business need |
| Implementation Services | Number of processes, automation complexity, custom object count | Start with one vertical slice and expand incrementally instead of a "Big Bang" | Proposal without a detailed Work Breakdown Structure (WBS) by process or workstream |
| Integrations | Number of systems, data format, need for middleware | Map dependencies upfront; choose between inexpensive iPaaS and costly custom API based on actual volume | No defined ownership for integration maintenance post-Go Live |
| Migration | Volume of records, duplications, number of historical sources | Conduct a data quality survey before estimation, not after | Proposal assumes "clean data" without actual verification |
| Training | Number of roles, process complexity, geographical dispersion | Train by role and scenario, not general screen-by-screen instruction | Training section limited to a single two-hour workshop for the entire organization |
| Ongoing Support | SLA, availability hours, monthly change scope | Define SLA level by process criticality, not uniformly | No distinction between "bug" and "change" in the support agreement |
| Hidden Internal Costs | Availability of process owners, quality of UAT, change management | Allocate a fixed percentage of the internal project manager's time upfront | Proposal assumes internal team will be "available" without estimated hours |

## Estimation Model: Effort Bands, Not a Price List

Instead of relying on a fixed price list that quickly becomes outdated and varies between vendors, it's better to think in terms of Effort Bands for each component, then translate these into a price with a specific vendor:

-   **Low Effort** - One business process, no complex integrations, fewer than 20 users, limited historical data. Typical for small B2B companies implementing basic Sales Cloud.
-   **Medium Effort** - Two to four business processes, one to three integrations with existing systems, 20-100 users, migration from a previous CRM system. This is the most common range in the US market.
-   **High Effort** - Multiple business units or countries, numerous integrations with legacy systems, complex permission model, more than 100 users, industry-specific compliance requirements.

For each effort band, a separate translation should be run for each of the seven components, and it should not be assumed that all components scale at the same rate. Integrations, for example, can jump from low to high effort even in a relatively small project if the existing system does not expose a functional API.

## How to Translate Effort Bands into a Real Proposal

Once the anticipated effort band is defined, the next step is to request a breakdown of hours by component from at least three vendors, not just a total sum. Such detail gives the organization real comparison capability: We've expanded on this in [Salesforce Consulting Guide](/en/insights/salesforce-consulting-guide), which also explains how to identify a proposal that artificially reduces the testing phase to appear cheaper.

### Three Typical Pricing Scenarios

**Scenario A - Small Initial Implementation**: One sales process, no integration, 10-15 users. Most of the cost is concentrated in implementation services and training; licensing and ongoing support are relatively small parts in the first year.

**Scenario B - Replacing an Existing CRM System**: Migration of thousands of records, 40-60 users, one integration to an accounting system. Here, migration and integrations can account for a third of the total budget, and this is precisely the component that initial estimates tend to underestimate.

**Scenario C - Multi-Year Expansion for a Large Organization**: Multiple business units, Salesforce already in place and needs Service Cloud or Data Cloud added. Hidden internal costs – time of process owners and IT managers – become the most significant component, sometimes exceeding licensing costs.

## Example Organizational Scenario

Suppose a multi-site manufacturer is soliciting proposals from three integrators for a Salesforce implementation. The cheapest bid is 35 percent lower than the others, but upon review, it's found to include only 40 hours of migration despite the organization having approximately 60,000 historical customer records in an old system with many duplicates. The team asks the vendor to detail their assumptions and discovers the proposal assumed "clean data ready for transfer"—an assumption not verified against reality.

The organization decides to conduct a short data quality survey before signing a contract. The survey reveals that 18 percent of records are duplicated and 30 percent lack a mandatory field for the new process. Consequently, the organization asks all three vendors to re-price the migration phase based on the findings, and adds a clause to the contract distinguishing between one-time migration costs and ongoing data quality maintenance—as detailed in [Salesforce SOW Contract Clauses](/en/insights/salesforce-sow-contract-clauses).

The result: The chosen proposal was not the cheapest in the end, but it was the only one that included all seven cost components in realistic detail, including an estimate of internal hours from the organization itself. This change in order – first mapping out the true cost, then comparing proposals – is what prevented a budget overrun of approximately 25 percent that was discovered only in the fourth month by one of the competitors who chose the cheapest bid.

## Common Risks and Preventive Actions

| Risk | How it Appears in Practice | Preventive Action |
|---|---|---|
| Overly "Round" Proposal | A single total sum without breakdown by component | Demand a breakdown of hours and costs for each of the seven components |
| Ignoring Internal Costs | Organization fails to budget internal management time and UAT | Estimate internal person-hours upfront, separate from vendor cost |
| Underestimated Migration | Assumption that "data is fine" without verification | Conduct a data quality survey before final estimation |
| Training as a Minor Item | Limited training budget for a single day for the entire organization | Budget training by role and actual scenario |
| Support Without Defined SLA | Vague support contract regarding response and resolution times | Establish a tiered SLA by criticality and price accordingly |

At the management level for a Salesforce implementation budget, this table is a starting point, not an exhaustive list. For CEOs, procurement, and CIOs, it's advisable to update it with each round of proposals and check which risks materialized in previous projects within the same industry before approving a final budget.

## How to Verify That the Estimate is Reasonable

| Area of Verification | What to Check | Check Frequency |
|---|---|---|
| Licensing vs. Actual Use | Percentage of active users relative to the number of licenses purchased | Quarterly |
| Implementation Services Overrun | Actual hour deviation versus hours quoted in the proposal | At each milestone |
| Integration Load | Frequency of failures or delays in data transfer between systems | Monthly |
| Migration Quality | Percentage of records with errors or duplicates after transfer | One-time after Go Live |
| Support Cost vs. SLA | Do actual response times match what was paid for | Monthly |

For responsible budget estimation, it's advisable to choose only three to five metrics from the table for ongoing tracking in the first year. A good metric can be calculated before and after contract signing, allowing for comparison between what was promised and what actually happened – rather than relying solely on a feeling that the project "went well." The actual implementation of the estimation model can be managed through [Consulting and Discovery Services](/en/consulting-discovery).

## Checklist Before Budget Approval

-   ☐ Each of the seven cost components is priced separately and not as a single lump sum.
-   ☐ A data quality survey was conducted before estimating migration costs.
-   ☐ An effort band (low, medium, high) was defined before requesting proposals.
-   ☐ Internal work hours were estimated separately from the vendor's cost.
-   ☐ Training budget is detailed by role, not as a general item.
-   ☐ A clear SLA is defined for the ongoing support agreement.
-   ☐ A reserve of 10-20 percent is allocated for scope changes.
-   ☐ At least three vendors provided a breakdown of hours by component, not just a total sum.
-   ☐ Licensing costs for 24-36 months were reviewed, not just for the first year.
-   ☐ Post-Go Live verification metrics were defined, not just a "system went live" criterion.

## Professional Resources

-   HPI Pro – Consulting and Discovery — https://hpi.pro/consulting-discovery
-   Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
-   HPI Pro – Salesforce Services — https://hpi.pro/services

### Questions and answers
**Why can two Salesforce implementation quotes vary by double or more?**
Often, it's about differing scopes of work, not a 'discount.' A cheaper quote might omit load testing, historical data migration, or end-user training, only to add these back as extra costs post-signature. Compare based on the same WBS and assumptions, not just the bottom-line number.

**Is it better to pay for premium licenses to save on implementation costs?**
Sometimes, yes: a license with built-in Flow and Automation capabilities can eliminate custom development. But it's not a fixed formula—three-year license costs can sometimes outweigh the implementation savings. Always calculate the total cost over 24-36 months, not just the one-time implementation price.

**How much budget should be allocated for changes during the project?**
For medium to large projects, it's common to reserve 10-15% of implementation service costs as a contingency for scope changes. If your organization is also undergoing significant process transformation, not just digitizing existing processes, consider increasing this to around 20%.

**What's the difference between one-time migration costs and ongoing data maintenance costs?**
Migration is a time-limited project: cleaning, mapping, and a one-time transfer. Data maintenance is an ongoing process—deduplication, quality control, and permission updates. Organizations that only budget for migration often find data quality has declined again within a year.

**How can you tell if a proposal hides internal costs?**
If the proposal doesn't specify how many hours of internal management, user acceptance testing, and process owner involvement are required from your team, it's likely these costs exist but aren't explicitly accounted for. Always request an estimate of internal human hours separately from the vendor’s cost.

---

## Choosing a Salesforce Implementation Partner: Your Definitive Guide to Making the Right Decision
URL: https://hpi.pro/en/insights/choose-salesforce-implementation-company
Selecting a Salesforce implementation partner often swings between two extremes: being swayed by a dazzling demo or fixating solely on the lowest price. A truly effective selection process delves into core expertise, authentic testimonials, and engagement models — long before even glancing at the numbers.

## The Short Answer

Choosing a Salesforce implementation partner often falls into one of two dangerous traps: being impressed by a dazzling demo during a sales meeting, or simply comparing prices between seemingly similar proposals. Neither method truly assesses what determines success – does the vendor understand your business process, how do they handle exceptions, and what happens when something goes wrong in the third week of the project?

A mature selection process sequentially evaluates four key areas: defining your internal needs before approaching the market, identifying the right type of vendor for your scope and risk tolerance, assessing professional depth beyond a mere demo, and structuring an engagement model that fairly distributes risk. We've extensively covered how to compare bids and terms in [Comparing Salesforce Proposals](/en/insights/compare-salesforce-proposals); here, the focus is on the preceding step – how to even arrive at a worthy list of candidates.

## Step One: What You Actually Need Before Going to Market

The most common mistake is asking vendors "How much does it cost?" before defining what "it" even is. A company that starts a procurement process without a written scope receives proposals that are impossible to compare, as each vendor fills in the gaps with their own assumptions. Before the first meeting, have a brief document outlining: the business process requiring change, who the users are, current systems in place, and what success will look like in six months.

This scope inherently dictates the appropriate pricing model – a project with a clear scope is better suited for a fixed price, while an exploratory project fits a Time & Material approach. We've detailed this in [Salesforce Project Pricing Models](/en/insights/salesforce-project-pricing-models). Organizations that skip the definition phase almost always pay for it twice: once with an inflated quote covering uncertainty, and again with scope changes mid-project.

## Vendor Types: Boutique, Global, and Freelance

The Israeli market for Salesforce services broadly divides into three categories, each suitable for a different risk profile.

**Boutique firms** typically comprise 5 to 30 employees, specialize in one or two areas (Sales, Service, Marketing Cloud), and provide direct access to a senior architect throughout the project. Their advantage is agility and competitive pricing; the drawback is limited capacity – a large project requiring five people simultaneously might get stuck in a queue.

**Global integrators** bring documented methodologies, rapid scaling capabilities for additional personnel, and experience from similar sectors worldwide. Their pricing is 30-60 percent higher than boutique firms, and often there's a project management layer separating the client from the actual execution team – which can slow communication during a crisis.

**Freelancers** offer the lowest hourly rates but expose you to single-person dependency. If the freelancer falls ill, travels abroad, or moves to another project, work grinds to a halt. Best suited for ongoing maintenance or small projects with a defined and contained scope.

## Assessing Professional Depth Beyond a Demo

An impressive demo proves the vendor knows how to showcase Salesforce, not that they can solve your organization's specific problem. True in-depth assessment requires three layers: First, request that the actual project execution team (not just sales personnel) participate in the meeting and answer technical questions. Second, ask for a concrete example of a similar project in scope and industry, including real screenshots, not marketing slides. Third, observe how the vendor responds to a trick question – for instance, "What happens if, mid-project, we discover the source data is unreliable?" An experienced vendor will respond with an example, not a platitude.

The individual actually leading the architecture determines the quality of the solution far more than the logo on the invoice. It's crucial to ensure that the architect presented in the sales meeting is indeed the person who will be involved in the project, and not a "face" shown to clients who is then replaced by a more junior team after signing.

## Checking Actual References

A good reference call goes beyond "Would you recommend them?" and delves into operational details. Three questions that yield real information: Was the project completed within the original budget and timeline, and if not, what was the deviation and its cause? What happened when a mistake or bug was found in production, and how long did it take to fix? And, is the team that executed the project still employed by the vendor today? High employee turnover at an implementation company indicates that the knowledge gained from previous projects is no longer available.

It's advisable to request at least two references: one from a successful project and one from a project that encountered difficulties. A vendor who refuses to provide a "problematic" reference or claims all their projects were flawlessly successful is likely hiding something.

## Engagement Model: How to Share the Risk

The engagement model determines who bears the risk when reality deviates from the plan – which happens almost always.

| Model | When Suitable | Primary Risk |
| --- | --- | --- |
| Open Time & Material | Immature scope, Discovery phase | Exceeding hours without a cap |
| T&M with Cap | Partial scope, first project with vendor | Requires ongoing monitoring against cap |
| Fixed Price | Well-defined and documented scope | Vendor might cut corners to maintain margin |
| Monthly Retainer | Ongoing maintenance and support | Actual work volume doesn't always match payment |

For a first project with a new vendor, a T&M with cap model is often the most balanced choice: it prevents budgetary surprises but doesn't incentivize the vendor to cut corners on testing. Consider moving to a fixed price only after the scope has been validated against real end-to-end scenarios, as described in [Choosing a Salesforce Vendor](/en/insights/salesforce-vendor-scorecard).

## Vendor Scoring Scorecard

A weighted scoring table transforms subjective comparison into a process that can be defended to management. Suggested weights for a typical project:

| Criterion | Weight | What to Actually Check |
| --- | --- | --- |
| Experience Match to Industry & Process | 25% | Similar projects in scope and sector, not just a recognized logo |
| Depth of Proposed Team | 20% | Tenure and actual role of architect and developers |
| Quality of Proposal & Scope | 20% | Detailed WBS, assumptions, exclusions, and written acceptance deliverables |
| References & Employee Turnover | 15% | Direct conversations with past clients |
| Engagement Model & Contractual Fairness | 10% | Reasonable risk distribution, not just low price |
| Cultural Fit & Communication Availability | 10% | Response time, language, time zone, and update frequency |

Each vendor receives a score of 1-5 for each row, multiplied by the weight. The gap between the leading vendor and the second is as important as the score itself – a gap of less than 5 points usually warrants an additional clarification meeting before a final decision.

## Red Flags to Identify Early

- A quote without detailed hours by topic, only a global "total"
- Promising a "complete Salesforce solution" for a need never deeply investigated
- Refusing to reveal who on the team will actually perform the work
- Pressure to sign quickly "because this price is only valid this week"
- No reference to a failed case or a project that had difficulties
- A contract that doesn't define what constitutes project "completion" and final acceptance

## What to Ask to See in a Meeting: A Short Checklist

- ☐ Presence of the actual execution team, not just a salesperson
- ☐ Concrete example of a similar project with real screenshots
- ☐ Preliminary WBS detailing assumptions and written exclusions
- ☐ Name and contact information for at least two references
- ☐ Proposed engagement model with an explanation for its suitability to the scope
- ☐ Description of the process for handling scope changes and post-launch bugs

## Example Organizational Scenario

A medium-sized financial services company evaluated three proposals for Salesforce Sales Cloud: a local boutique, a global integrator, and a highly recommended freelancer. Management initially leaned towards the freelancer due to a 40 percent lower price, until a reference call revealed that his previous project was halted for three weeks when he fell ill. The organization ultimately chose the boutique, after the scorecard showed a 12-point advantage in the "team depth" and "low employee turnover" categories.

The project indeed encountered a mid-course requirement change – a new need for integration with an internal billing system not mentioned in the proposal phase. Thanks to the T&M with cap model, the change was handled as a pre-agreed addition rather than a renegotiation of the entire contract. Organizations deliberating between similar vendors and seeking additional question frameworks can utilize [Questions Before Choosing a Salesforce Integrator](/en/insights/questions-before-choosing-salesforce-integrator).

## How to Measure if the Choice Was Correct

| Metric | What to Check | When to Check |
| --- | --- | --- |
| Adherence to Timeline | Deviation in days between plan and actual execution | At each milestone |
| Team Stability | Did the same people accompany the project to completion? | At the end of each phase |
| Handling Exceptions | Response time for a bug or requirement change | Throughout the project |
| Documentation Quality | Can maintenance be handed over to another team without single-person dependency? | Upon delivery |

A metric that cannot be practically checked is not a metric. If the contract doesn't include a clear definition of what constitutes project "completion," it's almost impossible to know if the choice was correct until it's too late to fix. An organization seeking external guidance in building its selection process can start with [Consulting & Discovery Services](/en/consulting-discovery), which helps define scope and build a tailored scorecard even before going to market.

## Professional Resources

- HPI Pro – Consulting & Discovery — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Services — https://hpi.pro/services

### Questions and answers
**What's the practical difference between a boutique firm and a global integrator for a Salesforce project?**
Boutique firms typically offer direct access to senior architects and developers, shorter work cycles, and a lower hourly rate, but may have limited capacity for very large projects. Global integrators bring structured methodologies and scalability, often at a higher cost and with more management layers between the client and the hands-on implementers.

**How does the cost of hiring a Salesforce freelancer compare to a consulting firm?**
A skilled freelancer might cost around $70-$120 per hour without management overhead, but exposes your organization to single-point-of-failure risk. A consulting firm typically charges 20-40% more but provides team backup, professional insurance, and project continuity even if an individual leaves mid-project.

**What key questions should I ask a consulting firm's references before signing a contract?**
Inquire about actual versus planned timelines, the quality of documentation received, how the vendor handled mistakes, and if the original project team members are still with the company. Evasive answers to any of these questions should be considered a significant red flag.

**What's the recommended engagement model for an organization's first Salesforce project?**
For initial Salesforce projects, it's often best to start with a Time & Material (T&M) model with a cap for the first phase. Transition to a fixed-price model only after the scope has stabilized around clearly defined end-to-end scenarios. A fixed price on a vague scope incentivizes the vendor to cut corners to protect profitability.

**What is the minimum team size required from a vendor for a medium-sized Salesforce project?**
For a project spanning 3-6 months, ensure the vendor provides at least two individuals with sufficient expertise to back each other up: an architect or lead, and an additional developer. A one-person team works well until that person is sick, on vacation, or leaves the company.

---

## How Long Do Salesforce Projects Really Take? Timelines, Dependencies, and Hidden Delays
URL: https://hpi.pro/en/insights/salesforce-project-timeline
An average Salesforce project can span from six weeks to nine months. However, the quoted timeline rarely hinges on development scope alone; it's often driven by decision-making pace, data readiness, and the availability of key organizational stakeholders.

## The Short Answer

There's no single answer to how long a Salesforce project takes, but knowing the realistic ranges before signing a quote is helpful. A focused "Quick Win" project—a single automation, a custom object, an advanced report—can often be completed within 3-4 weeks. A full Sales Cloud implementation for a mid-sized sales team typically ranges from 8 to 14 weeks. A multi-cloud project with integrations to ERP and external systems can take 6-9 months, and sometimes longer if multiple business units are involved.

The actual timeframe primarily depends not on the code's scope but on the organization's decision-making pace: who owns each process, how long it takes to approve the scope, and when the data is truly ready for testing. Before setting a Go-Live date, it's also worth reading the full guide to [Salesforce Implementation in your Organization](/en/insights/salesforce-implementation-guide), which details the work stages behind each week of the timeline.

## Why Timeframes Vary So Much Between Seemingly Similar Projects

Two organizations requesting "Sales Cloud implementation for a 20-person sales team" might receive quotes differing by as much as threefold in execution time, and both quotes could be accurate. The difference almost always stems from what isn't explicitly stated in the requirements document: how many existing data sources there are, how complex internal approval processes are, and how quickly the organization makes decisions affecting more than one department.

A project with a single Product Owner who has the authority to sign off on the scope progresses significantly faster than a project where every change requires steering committee approval. This isn't a technical difference—it's an organizational one that directly impacts the timeline, sometimes more than any architectural decision.

## Timeframes by Project Type

The following table provides estimated actual elapsed (not effort) work weeks by stage and project type. These are average ranges from real-world experience, not a commitment—each specific project requires a separate assessment.

| Stage | Quick Win / Point Solution | Standard Implementation (Single Cloud) | Multi-Cloud Project with Integrations |
| --- | --- | --- | --- |
| Discovery & Requirements | 3-5 days | 1.5-3 weeks | 3-6 weeks |
| Architecture & Data Model | 2-3 days | 1-2 weeks | 3-5 weeks |
| Build & Configuration | 1-2 weeks | 3-6 weeks | 8-16 weeks |
| Data Migration | Not usually required | 1-2 weeks | 3-6 weeks |
| Integrations | Not usually required | 1-3 weeks | 4-10 weeks |
| UAT & Bug Fixes | 2-4 days | 2-3 weeks | 3-5 weeks |
| Go Live & Hypercare | 2-3 days | 1-2 weeks | 2-4 weeks |
| **Total Overall Duration** | **3-4 weeks** | **8-14 weeks** | **24-40 weeks** |

It's important to remember that the numbers in the table assume reasonable availability of stakeholders and data of reasonable quality. Any of these assumptions, when unmet, can add entire weeks to each stage.

## What Really Delays Projects – Not What You Think

When a Salesforce project runs over schedule, the most common cause isn't technical complexity but one of five things:

- **Pending decisions not made in time** - A business question remains open for two weeks because no one is authorized to answer it, while the technical team waits.
- **Data that isn't actually ready** - A "current and ready" data source turns out to contain duplicates, missing fields, or conflicting information from two sources.
- **Availability of content owners and process owners** - Sales or service personnel who need to review and approve are busy with their regular duties and haven't been pre-allocated.
- **Third-party integrations** - Dependency on an external vendor, an API with limitations, or an internal IT team not working at the same pace.
- **Rolling UAT** - Because testing only begins when the system is "almost ready" rather than in parallel with development.

Among these, pending decisions are the easiest to prevent and most common in practice. An organization that defines in advance who approves what, and within how many days a response is considered a "delay," saves an average of two to three weeks on a medium-sized project. This topic is also extensively covered in [Salesforce MVP](/en/insights/salesforce-mvp-scope), which explains how to reduce the number of pending decisions from the outset by scoping a smaller first version.

## The Critical Path: What Determines the Final Date

In every project, there's a single chain of activities that determines the minimum completion date—this is the critical path. In a typical Salesforce project, the critical path almost always passes through three bottlenecks:

1.  **Approval of the data model and permissions** - Until this is finalized, integration or migration cannot confidently begin.
2.  **Readiness of the data source for migration** - Even if development is complete, going live is impossible without clean, validated data.
3.  **Availability of process owners for UAT** - This is often the narrowest bottleneck because it involves people with full-time roles in the organization, not just project team time.

A one-week delay in any of these three directly rolls into the Go-Live date, even if the rest of the team meets their deadlines. Therefore, a good PMO specifically monitors items on the critical path, not just the overall project completion percentage. This concept is practically applied in the [Salesforce UAT guide](/en/insights/salesforce-uat-guide), which details how to plan the testing phase so it doesn't become another bottleneck itself.

## Phased vs. Big Bang: How the Choice Impacts the Timeline

The question of whether to go live in one fell swoop (Big Bang) or in waves (Phased) is one of the most significant decisions regarding the timeline, not just operational risk.

**Big Bang** is suitable when the scope is relatively small, when there's a tight dependency between components (e.g., a unified Lead-to-Cash process that cannot be split), and when the organization prefers a concentrated time investment over a prolonged transition period. The timeline advantage: a single clear target date. The disadvantage: any delay in one component halts the entire date.

**Phased** is suitable when the scope is broad, when there are multiple departments or processes that can be segregated, and when the organization wants early value and to learn from one wave before progressing to the next. The advantage: the first wave goes into production faster, and lessons learned are applied in subsequent waves. The disadvantage: a longer overall duration, and sometimes higher coordination costs between waves.

As a rule of thumb, if the project is expected to exceed 4 months or involves more than two independent departments, a Phased approach almost always shortens the time to the first business value, even if the total project duration is similar or longer.

## How to Shorten a Timeline Without Sacrificing Quality

There are genuine ways to shorten, and there are shortcuts that seem like time-saving but only defer the cost to Hypercare or the following year.

**What genuinely shortens:**

- Tight scope definition for the first version, with an explicit, pre-approved list of "not now" items.
- Appointing a single Product Owner with real authority to approve or reject, to eliminate committee delays.
- Starting data cleansing work concurrently with requirements gathering, not after.
- Prioritizing calendar time for process owners for planned UAT, not just when the stage arrives.
- Using standard Salesforce components instead of custom development wherever possible.

**What seems like shortening but isn't really:**

- Skipping full UAT and going straight to "developer testing"—saves a week and creates a month of production fixes.
- Data migration without cleansing, with the intention to "clean later"—dirty data becomes an adoption problem.
- Cramming training into one day before Go-Live—leads to system workarounds in the first few weeks.

When a project's timeline is truly critical to the business, professional guidance through [Salesforce Implementation Services](/en/salesforce-implementation) focuses precisely on this combination—which shortcuts are safe and which merely defer costs.

## Example Organizational Scenario

A logistics company planned a Service Cloud implementation within 10 weeks to be ready before peak season. In the second week, it became clear that the existing ERP system wasn't ready to expose a stable API, and the internal IT team was only available part-time for the project. Instead of pushing the entire project forward, the team switched to a Phased approach: the first wave included basic case routing and SLA, without ERP integration, and went live within 7 weeks—three weeks before peak season. Full integration was deferred to a second wave, which ran concurrently with peak season itself and went live two months later.

The main takeaway: when a real obstacle is identified on the critical path, the right question is not "how do we compress the remaining time" but "what can be separated into a distinct wave without compromising immediate value." The Hypercare planning after each such wave is detailed in [Salesforce Hypercare](/en/insights/salesforce-hypercare-plan), which shows how to stabilize each wave before moving to the next.

## Checklist for Planning a Realistic Timeline

- ☐ A closed scope for the first version has been defined, including a "not now" list.
- ☐ A single Product Owner with approval authority has been appointed.
- ☐ Data quality has been checked at the source, not just assumed to be "ready."
- ☐ Process owners have been pre-allocated time for planned UAT.
- ☐ Third-party integrations have been checked against API and vendor availability.
- ☐ A clear decision has been made: Phased or Big Bang, and why.
- ☐ The critical path is identified and monitored separately from the overall completion percentage.
- ☐ A built-in buffer of 10-15% is included in the timeline, not a promise of "everything on time."
- ☐ End-users have been trained before Go-Live, not the day before.
- ☐ A Hypercare plan is defined in advance with an exit criterion.

## Professional Resources

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Implementation — https://hpi.pro/salesforce-implementation
- HPI Pro – Methodology — https://hpi.pro/methodology

### Questions and answers
**What's the difference in project length between a basic Sales Cloud and a Service Cloud with integrations?**
A basic Sales Cloud for a single sales team, without heavy integrations, typically wraps up in 6-10 weeks. A Service Cloud with routing, SLAs, and 2-3 integrations (ERP, telephony, billing system) generally requires 12-20 weeks due to more complex service process mapping and permission sets.

**How much of the total project timeline does the data phase typically consume?**
In projects with a single, clean data source, data cleansing and migration account for roughly 10% of the total time. With two or more sources riddled with duplicates, this jumps to 25-30%, as each quality assurance round uncovers more anomalies requiring business decisions, not just technical fixes.

**Is a fixed, upfront project schedule better, or an evolving estimate?**
A locked-in schedule is only effective when the scope is completely finalized and there are no external integration dependencies. Most projects benefit from a flexible range (e.g., 10-14 weeks) updated after each sprint. слишком early rigidity often leads to quiet scope creep rather than true adherence to goals.

**What happens to the timeline if an unforeseen integration need arises mid-project?**
In a phased project approach, the integration can be deferred to a later wave without halting other work, typically adding 2-4 weeks for a separate phase. In a 'Big Bang' approach, this discovery often grinds the entire process to a halt, as all components are expected to launch simultaneously.

**How much time should be allocated for UAT to prevent it from becoming a project bottleneck?**
For a medium-sized project, we recommend 2-3 weeks for UAT, including one round of bug fixes. The common challenge isn't UAT duration itself, but stakeholder availability. If process owners aren't freed from their daily tasks in advance, a stage meant for two weeks can stretch into six.

---

## Salesforce Implementation for Large Enterprises: Principles, Governance, and Risks
URL: https://hpi.pro/en/insights/enterprise-salesforce-implementation
For organizations with 500+ users, the challenge shifts from 'how to build' to 'who decides,' 'who approves changes,' and 'how to coordinate parallel initiatives.' This article covers Governance models, Single-org vs. Multi-org considerations, and common pitfalls.

## The Short Answer

In an organization with dozens of users, Salesforce implementation primarily involves configuration and adoption. However, in an organization with 500+ users, spanning multiple business units and perhaps several countries, the central challenge shifts: who approves changes, how do parallel teams avoid stepping on each other's toes, and does the Org structure support future growth or constrain it? Without proper Governance, every isolated improvement becomes a risk to the stability of the entire organization.

This article focuses on the management layer above the individual project: decision-making structures, choosing between a Single-org and multiple separate Orgs, coordinating releases, security and compliance, global localization, and interdependencies between parallel programs in the PMO. The foundational steps for basic implementation are detailed in [Salesforce Implementation in an Organization](/en/insights/salesforce-implementation-guide), and this article builds upon that at an enterprise scale.

## Why Scale Changes Everything

In a project with 50 users, changes can be managed through a conversation between two people. With 500 users or more, there are typically several development teams, various business units with different priorities, and sometimes multiple parallel implementation vendors. A minor change to a shared Object—adding a required field, modifying a Validation Rule—can break a process in another unit that was unaware of the change.

Therefore, at an enterprise scale, three questions precede any technical discussion: Who owns each key Object and process? What mechanism verifies cross-team impact before deployment? And who is authorized to halt a release if a risk is identified? Organizations that skip these questions build "quickly" at first but pay for it with frequent outages and unplanned rollbacks within a year or two.

## Governance and Change Advisory Board (CAB)

A Change Advisory Board is not a bureaucratic committee; it's a mechanism that prevents a seemingly small change by one unit from negatively impacting another. The recommended structure includes three levels of approval: routine configuration changes (Low risk) approved at the team level; changes affecting a shared data model or integration (Medium risk) reviewed by the weekly CAB; and architectural changes (e.g., changing the Sharing Model or migrating to Multi-org) requiring Steering Committee approval at the CIO level.

In practice, the most effective CAB we’ve observed isn't the one with the most documentary transparency, but the one with a clear SLA: a Medium risk change request receives a response within 3-5 business days, not "at the next meeting, whenever that may be." When the SLA isn't met, teams learn to bypass the process, and that's precisely when Governance collapses in practice, even if it exists on paper.

### Enterprise Governance Responsibility (RACI) Chart

| Decision Area | Business Sponsor | Enterprise Architect | Release/DevOps Lead | Security & Compliance | PMO |
| --- | --- | --- | --- | --- | --- |
| Org Structure (Single/Multi-org) | Consulted | Accountable | Informed | Consulted | Informed |
| Shared Object Change Approval | Informed | Responsible | Consulted | Consulted | Informed |
| Release Schedule and Release train | Informed | Consulted | Accountable | Informed | Responsible |
| Permissions and Compliance Policy | Consulted | Consulted | Informed | Accountable | Informed |
| Parallel Program Dependencies | Responsible | Consulted | Informed | Informed | Accountable |
| Localization for New Market | Accountable | Responsible | Informed | Consulted | Responsible |

This table is not a rigid template; it should be adapted to the actual organizational structure. The critical point is that "Accountable" appears only once per row—when two entities have full ownership of the same decision, it's the first sign that the structure will cause delays.

## Single-org vs. Multi-org

This is one of the most expensive decisions to rectify retrospectively. A Single-org with precise permission separation (Profiles, Permission Sets, Record Types, and Sharing Rules) allows for a single report across the entire organization, less integration maintenance, and lower licensing costs. The problem arises when different business units require completely different release frequencies, or when regulatory demands mandate physical data separation.

Multi-org solves the isolation problem but creates a new one: every cross-organization report requires a separate BI layer or a solution like Data Cloud, and every global process (e.g., Lead-to-Cash) must be built twice or managed via MuleSoft/synchronization mechanisms. In organizations that have evaluated both paths, migrating from Single-org to Multi-org after the organization has grown typically takes 9-14 months and involves complex data migration—therefore, it's better to make this decision early, even if it means temporarily compromising on permission separation.

## Release Train and Enterprise-Level DevOps

When several teams work in the same Org, releasing "when ready" ceases to function. The model that works at an enterprise scale is a Release Train: a fixed cadence (bi-weekly to monthly), a single Source of Truth in Version Control, and a Pipeline that identifies Metadata conflicts between teams before (not on) deployment day.

Practical components to include:

- A shared Integration environment where all teams merge before UAT
- A fixed Code Freeze window (usually 48-72 hours) before each release
- Automated regression testing that runs on core use cases for each business unit, not just the new changes
- A clear policy: a team that misses the merge deadline drops to the next train and doesn't hold everyone else up

Further detail on Sandbox infrastructure and Pipeline processes is covered in [Salesforce DevOps Sandboxes](/en/insights/salesforce-sandbox-devops-strategy), which also presents the recommended environment structure between Dev and Production.

## Security and Compliance at Enterprise Scale

Above 500 users, the permission model itself becomes a critical asset. A common mistake is creating a new Profile for every minor change, which within a year or two generates hundreds of Profiles whose logic no one remembers. The more effective approach: a restrictive Profile based on a broad role, and modular Permission Sets added as needed for specific requirements.

In global organizations, an additional layer of Compliance is added: GDPR in Europe mandates deletion capabilities and consent documentation, privacy regulations in Israel require database registration, and healthcare or financial organizations in the US may need to comply with HIPAA or SOX. The practical implications: field-level encryption for sensitive data, record access logs (Field Audit Trail or Shield), and a documentation process that shows who accessed what and when—not just who is authorized to access.

## Global and Localization

An implementation operating in multiple countries encounters three recurring problems: currencies and dates (Multi-Currency and date format by Locale), interface and report language (Translation Workbench doesn't always cover custom fields), and approval processes that conflict with local labor or tax laws. A team that plans localization as an add-on at the end of the project typically finds it requires changes to the data model itself, not just string translation.

## PMO and Parallel Program Dependencies

In a large organization, a Salesforce project rarely runs in isolation. ERP programs, Data Warehouse projects, and sometimes company mergers run concurrently. A PMO that doesn't map these program dependencies will discover late in the process that it and the ERP are simultaneously building two different sources of truth for the same customer data.

The practical tool is a dependency matrix updated monthly: for each program, what data it "leads" (Source of Truth), and what data it merely consumes. When two programs claim ownership of the same field, the PMO is the body that needs to adjudicate—not let it be resolved "in the field" between two developers.

## Typical Failure Patterns for 500+ Users

| Failure Pattern | How it Appears in Practice | Preventive Action |
| --- | --- | --- |
| Profile Sprawl | Hundreds of nearly identical Profiles, no one sure who can do what | Gradual transition to modular Permission Sets |
| Team "Private" Release | One team goes to Production without CAB, breaks another process | Mandatory Release Train with shared Code Freeze |
| Two Sources of Truth for Same Data | ERP and CRM each "owning" customer data | PMO establishes a single Source of Truth for each data domain |
| Overly Broad Permissions "To Avoid Blocking" | Sensitive data leakage between business units | Least Privilege by role, quarterly audit |
| Localization as a Late Add-on | Partial translation, incorrect date format, broken reports in one region | Plan Locale and currency in the data model from day one |
| Unsynchronized Sandbox | Tests pass in Sandbox but fail in Production due to config differences | Scheduled Refresh and consistent Seed Data policy |

## Recommended Workflow for Enterprise-Scale Implementation

### 1. Establish a Steering Committee and Change Advisory Board Before Building

Before writing the first line of code, appoint an executive-level Sponsor, define the three levels of change approval, and agree on an SLA for responses. Without this, the first teams to start working will effectively set the precedent for everyone who follows.

### 2. Decide on Single-org vs. Multi-org Early and Document the Rationale

This decision should be based on actual regulatory requirements and desired release frequency, not technical preference. Document the rejected alternative and the conditions that would warrant re-evaluation (e.g., acquiring a new company).

### 3. Build a Release Train Before You Have More Than One Team

A fixed cadence, a shared Integration environment, and a process for identifying conflicts before release day. The core project team is defined in [Salesforce Project Team Roles](/en/insights/salesforce-project-team-roles), but at an enterprise scale, a dedicated Release Manager role is also required.

### 4. Map Permission Model and Compliance Requirements by Operating Region

Identify in advance which regulations apply in each operating country and plan encryption, logs, and deletion processes accordingly, rather than as an add-on after a complaint or audit.

### 5. Document Program Dependencies in the PMO and Update Monthly

A living dependency matrix, not a document written once at the start of the project. Any schedule change in one program is checked against its impact on other programs.

### 6. Run a Pilot in One Business Unit Before Full Enterprise Rollout

A complete vertical slice, including real permissions and integrations, allows for identifying Governance and Release issues before they are multiplied across dozens of units. Understanding the building blocks at the User Story level is presented in [Salesforce User Stories](/en/insights/salesforce-user-stories-backlog).

### 7. Expand in Controlled Waves with Measurement Between Waves

Each Rollout wave is measured against a baseline before expanding to the next wave. If a first wave exposes a Governance issue, fix it before proceeding—don't expand while fixing.

## Example Enterprise Scenario

An insurance company with 1,200 users across three countries attempted to implement Salesforce with two parallel development teams—one for sales and one for service—without an active CAB. After five months, both teams were changing the same customer Object weekly, and testing processes intermittently failed without anyone knowing why. The solution wasn't technical: the organization established a weekly CAB with a 3-day SLA, designated a single Object Owner for each key entity, and transitioned to a bi-weekly Release Train with a shared Integration environment.

Within two months, the number of conflicts between teams significantly reduced, and the launch schedule across the three countries stabilized. The main lesson: enterprise scale doesn't fail due to technology, but due to a lack of clear ownership over shared data.

## Checklist Before Scaling to Enterprise

- ☐ A Change Advisory Board exists with a defined, active SLA
- ☐ The Single-org vs. Multi-org decision is documented with re-evaluation conditions
- ☐ A Release Train is in place with a fixed cadence and a shared Integration environment
- ☐ The permission model is based on Permission Sets, not a new Profile for every change
- ☐ Compliance requirements have been reviewed for each operating country
- ☐ A dependency matrix between parallel programs exists and is updated monthly
- ☐ A single Object Owner is defined for each shared data entity
- ☐ A Pilot has been conducted in one business unit before full rollout
- ☐ A localization plan exists that goes beyond string translation
- ☐ Separate success metrics have been defined for each expansion wave

## Professional Resources

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Implementation — https://hpi.pro/salesforce-implementation
- HPI Pro – Methodology — https://hpi.pro/methodology

### Questions and answers
**When does the need for a Multi-org Salesforce strategy become truly relevant?**
Multi-org becomes relevant when business units operate under vastly different sales models, regulatory frameworks, or languages, and when the frequency of changes in one unit could destabilize another. For most organizations up to 3,000-5,000 users, a Single-org with precise permission sets is still preferable due to significantly higher Multi-org maintenance costs.

**How long does it take to establish an effective Change Advisory Board (CAB)?**
On average, it takes six to eight weeks for the process to stabilize. This includes defining change types, approval thresholds, a fixed meeting cadence, and a standardized request template. The real challenge isn't defining the process, but enforcing it when business pressure urges circumvention.

**How do you plan a Release Train with 6-8 parallel agile teams?**
Establish a consistent release cadence (e.g., bi-weekly or monthly), a shared Code Freeze window, and a robust merge mechanism that identifies metadata conflicts before deployment. Teams not ready by the deadline move to the next train — the entire group is not held back.

**How do compliance requirements change when an organization operates in multiple countries?**
Region-specific mapping is required: GDPR in Europe, local data protection laws in other territories, and sometimes HIPAA or SOX for US healthcare and financial organizations. The practical difference often lies in data retention, field-level encryption, and access logs, not just profile permissions.

**What happens when a CRM initiative and an ERP initiative clash on the timeline?**
Often, integration dependencies or shared single sources of truth (e.g., customer data) are only discovered late in the process. A Project Management Office (PMO) should map program dependencies from day one, determining which program 'leads' for each data domain to prevent conflicting decisions on the same data fields.

---

## CRM Migration to Salesforce: Plan Your Move Without Losing Progress or Data
URL: https://hpi.pro/en/insights/replace-crm-with-salesforce
CRM system migrations often fail, not because of Salesforce itself, but due to poorly managed historical data transfers. This article details how to map your existing processes, strategically decide what to leave behind, and safely decommission your old system.

## The Short Answer

Replacing a CRM system with Salesforce isn't merely a technical "data transfer" project. It's an organizational decision about what's worth keeping, what to leave behind, and how to keep the business running during the transition. The most common failure isn't in the Salesforce design itself, but in the silent assumption that everything from the old system must be migrated as is.

The correct approach begins with process mapping, not table exports. This is followed by building a new data model that aligns with how the organization operates today, not a structure defined a decade ago in a different system. A controlled parallel operation period, and finally, a structured decommissioning of the old system with regulatory documentation, complete the process.

Organizations grappling with these questions will find additional context in [Salesforce Implementation in an Organization](/en/insights/salesforce-implementation-guide), which details the comprehensive decision-making process for a Salesforce project.

## Mapping Existing Processes: Not Export, But Understanding

The first step in any CRM system migration isn't to hit "Export," but to sit with process owners and understand what actually happens between lead generation and deal close, or between inquiry receipt and service case resolution. An old process document, if it even exists, is almost always outdated compared to current actual operations.

During mapping sessions, it's crucial to document not just the official steps, but also the "shadow processes" — parallel Excel files, fields no one uses, approvals happening via WhatsApp instead of through the system. These are precisely the areas where a new system, even if well-built, will fail adoption if not accounted for.

The mapping output should include a table of core processes, the process owner, frequency of use, and dependence on the old system. A process run once a quarter that generates a critical regulatory report demands a different approach than a high-volume daily process. This categorization also determines the order of migration and the level of testing required for each process.

## What Not to Migrate: A Decision That Saves Half the Work

One of the most significant decisions in a CRM migration project is not what to migrate, but what **not** to migrate. Most venerable systems, accumulated over years, contain layers of duplicate fields, superseded statuses, and processes defined for a one-off project that has long since concluded.

A practical rule of thumb: any object or field untouched in the last two years goes onto the "do not migrate" list by default, unless a specific process owner provides a justified exception. This list is built against actual usage logs from the old system, not user memory, because human memory often describes how the system was _supposed_ to work, not how it _actually_ works.

It's important to distinguish between three categories of information:

- **Live Data** – Must be migrated to the new system as active records with all their relevant links.
- **Relevant Historical Data** – Migrated as an archive for viewing, usually without the need for editing or automation.
- **Dead Data** – Not migrated at all, kept only in an external backup in case of audit.

Further details on managing the boundaries between the planning and build phases can be found in [Salesforce Scope Creep](/en/insights/salesforce-scope-creep-change-control), as the tendency to "add a little more old data" is one of the most common sources of scope creep in these types of projects.

## New vs. Old Data Model: Not Translation, But Design

A common mistake is approaching the data model as a 1:1 translation — every table in the old system becomes a Salesforce object, every column a field. Such an approach preserves all the weaknesses of the old system within a new platform, missing out on Salesforce's key advantage: the ability to build flexible relationships between objects, built-in automation, and a rich permissions layer.

A comparison between the two main migration approaches helps inform a conscious decision:

| Aspect | Lift-and-Shift (Migrate As Is) | Redesign (New Design) |
| --- | --- | --- |
| Project Time | Relatively short, usually 6-10 weeks | Longer, typically 3-5 months |
| Business Process Fit | Low — preserves old limitations | High — built around current process |
| Technical Debt Risk | High, emerges after 1-2 years | Lower, as structure is planned upfront |
| Future Maintenance Costs | Increases over time | Relatively stable |
| Suitable for | Organizations with extreme time pressure or very limited scope | Most organizations moving from a system older than three years |
| Primary Risk | "New system, old problems" | Schedule overruns if scope isn't contained |

In practice, most organizations choose a hybrid approach: Redesign for the core model (accounts, contacts, opportunities, or service cases), and controlled Lift-and-Shift for secondary entities with no major procedural impact. This decision must be explicitly made during the planning phase, not emerge haphazardly during development.

## Parallel Run Period: Maintaining Business Continuity

The parallel run period is the timeframe during which both systems operate side-by-side — typically between four and eight weeks. Its purpose is to expose gaps in real-time, before they become irreversible problems. A closed sale, an opened service request, or a generated commission report — all of these should be checked in parallel in both systems and show identical or explainable results.

A question that arises in almost every project: Which system is considered the "source of truth" during this period? The answer must be singular and predefined, usually Salesforce from day one, with the old system used only for validation and not for day-to-day operations. Users performing double entry in both systems is a recipe for fatigue and eventual abandonment of the new system.

Practical tools for managing the period:

- Daily or weekly comparison report between key data points in both systems (number of leads, deal value, open cases).
- A live exception list updated immediately upon gap discovery, with an owner responsible for closing it within a defined timeframe.
- A group of "anchor users" from each department who report daily on usability issues, not just technical glitches.

Much of the insights gathered during this period are also relevant to the formal testing process, detailed in the [Salesforce UAT Guide](/en/insights/salesforce-uat-guide), and the post-launch period, described in the [Salesforce Hypercare Plan](/en/insights/salesforce-hypercare-plan).

## Decommissioning the Old System: Not a Single Event, But a Series of Decisions

Decommissioning the old system happens in stages, not with a single button press on cutover day. The guiding principle: the system is disconnected from daily operations immediately upon Go Live, but remains accessible for read-only access for a short grace period, usually 30-60 days, in case a missing data point or a question from the finance team arises.

### Cutover Decision Checklist

Before announcing the official decommissioning of the old system, it's advisable to ensure:

- ☐ All reports regularly generated from the old system have been successfully replicated from Salesforce or from the archive.
- ☐ One full business cycle (e.g., a complete closing month) has been completed entirely within the new system.
- ☐ Data discrepancies between systems have fallen below a predefined threshold (e.g., less than 1% of records).
- ☐ Written confirmation has been obtained from the legal or financial department that the archive meets retention requirements.
- ☐ Responsibility for read-only access during the grace period has been defined, as has the timeline for its final closure.
- ☐ A full and verified backup of all old system data has been performed before license cancellation.
- ☐ Notification has been sent to all process owners regarding the final decommissioning date and how to access the archive.

Skipping any of these items is the most common reason why, months after the project, it's discovered that required information for a tax audit or legal dispute is inaccessible.

## Archive and Regulation: What Must Be Stored and For How Long

Data retention requirements vary between industries, but there is almost always a mandate to retain financial, contractual, or customer complaint-related data for a period of seven years or more. A common mistake is trying to "push" all this history into Salesforce as live records, which burdens performance and confuses users who see decade-old transactions in their daily lists.

The common solution is a separation into two layers:

| Layer | Content | Location | Accessibility |
| --- | --- | --- | --- |
| Live Operational Data | Last 24-36 months | Salesforce | Full, including editing and automation |
| Regulatory Archive | Full history as required by law | External data warehouse or Salesforce Archive | Read-only, with search capability |

It's crucial to document the archiving policy in writing and obtain legal approval before revoking access to the old system, because once the license is cancelled, there's no turning back if data is found to be missing.

## Example Organizational Scenario

A financial services company migrated from a 12-year-old on-premise CRM system to Salesforce. The team identified during the mapping phase that approximately 40% of existing fields had not been touched for two years or more, and decided to exclude them from the migration. This saved about a month of effort in development and testing.

During the six-week parallel run period, a discrepancy in commission calculation was discovered due to a difference in number rounding between the systems — an error that would not have been found without a daily comparison report. The team corrected the formula before it affected actual paychecks. The old system was disconnected from daily operations on Go Live day, but read-only access was maintained for an additional 45 days for verification of a quarterly report that was already in progress.

The result: within three months of final decommissioning, no further access to the old system was required, and the savings in licensing costs covered a significant portion of the migration project cost itself.

## Common Risks and Prevention Measures

| Risk | How it appears in practice | Prevention Measure |
| --- | --- | --- |
| Migrating "everything" without filtering | The new system is cluttered with dead data, slowing adoption | Define a filtering criterion based on actual usage in the last two years |
| Copied data model | The same limitations of the old system reappear in Salesforce | Design a new model around the current process, not the old tables |
| Parallel run without an Owner | Discrepancies between systems are discovered late or not at all | Periodic comparison report with a designated owner for each exception |
| Too hasty decommissioning | Missing data is discovered after the license has been cancelled | A grace period of read-only access before final cancellation |
| Ignoring archiving requirements | Regulatory audit reveals required information was not properly retained | Obtain written legal approval of the archiving policy before cutover |

## How to Measure Migration Success

| Area | What to Measure | Measurement Frequency |
| --- | --- | --- |
| Data Integrity | Percentage of records successfully migrated without error | Before and after each migration run |
| System Alignment | Discrepancies in key reports between old and new | Daily during the parallel run period |
| User Adoption | Percentage of work done in the new system versus reverting to old | Weekly in the first month |
| Operational Cost | Savings in licensing and maintenance after decommissioning | Monthly, starting three months after Go Live |

For a Salesforce CRM system replacement, it's advisable to choose only three to five metrics upfront and measure them both before and after the project – otherwise, it's difficult to prove that the migration actually improved a process rather than just moving it to another platform. The actual execution of such a process can be carried out with the assistance of [Salesforce Implementation services](/en/salesforce-implementation), which guide organizations from the mapping phase all the way to decommissioning the old system.

## Professional Resources

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Implementation — https://hpi.pro/salesforce-implementation
- HPI Pro – Methodology — https://hpi.pro/methodology

### Questions and answers
**How much historical data should we migrate from our old system?**
A good rule of thumb: migrate the last 24-36 months of data as active records in the new system. The rest can be moved to an accessible archive. Transferring a decade of history 'just because you can' inflates migration costs and impacts performance without clear business benefit.

**What should we do with fields that don't have a direct equivalent in the new data model?**
First, determine if the field is still used in an active process or if it's a historical relic. An active field requires explicit mapping or a new Custom Field. A defunct field should only be saved in an external archive, not brought into Salesforce as a 'free text field' that no one will understand a year from now.

**How long should the parallel run period between systems last?**
Typically, four to eight weeks for a medium-sized organization, depending on the complexity of your sales or service cycle. Too short a period might miss seasonal exceptions; too long encourages users to stick with both systems, hindering adoption.

**When is it safe to permanently decommission the old system?**
Only after three conditions are met: data reconciliation between systems shows no significant discrepancies, at least one full business cycle has been successfully completed entirely within Salesforce, and all regulatory or audit reports that relied on the old system can be successfully replicated from the archive.

**Do we need to maintain live access to the old system after migration?**
Generally, live access isn't needed beyond a short grace period of 30-60 days for exceptional checks. After that, a backup for regulatory and audit purposes is sufficient in most industries, significantly reducing licensing and maintenance costs compared to keeping the old system fully active.

---

## Salesforce-ERP Integration: Architecture, Patterns, and Pitfalls
URL: https://hpi.pro/en/insights/salesforce-erp-integration
In any Salesforce-ERP integration, there comes a moment when two numbers conflict—inventory, outstanding balance, or order status. Someone has to decide which one is correct. This guide grounds that decision in a 'single source of truth,' effective synchronization patterns, and robust failure planning, rather than just a list of API connections.

## The Short Answer

Connecting Salesforce to an ERP often fails, not due to technical issues with the connection itself, but because a crucial question wasn't asked upfront: Which system is the source of truth for each entity, and what happens when messages between systems are lost, duplicated, or arrive out of order? This guide frames the decision around three layers—source of truth, synchronization pattern, and error handling—and demonstrates how to choose between them based on actual business scenarios, not just what the API allows.

The recommended approach is to start with the entities (customer, product, order, invoice) rather than the tools. For each entity, define a single owner, a reasonable update frequency, and who is authorized to make changes. From there, the synchronization pattern, error handling, and required monitoring level are derived.

A natural continuation of this discussion on connecting Salesforce to ERP is found in [Salesforce Architecture](/en/insights/crm-architecture-guide).

## Source of Truth for Each Entity: The Question Before Any API

Before choosing a protocol or integration tool, you must answer one question for each entity: Which system decides what's correct when there's a conflict? Typically, ERP is the source of truth for inventory, pricing, invoices, and financial transactions, while Salesforce is the source of truth for customer relationships, opportunities, and sales activities. The problem begins when someone silently assumes that both directions will "sort themselves out"—leading to situations where a sales rep changes a shipping address in Salesforce while the ERP has already dispatched the shipment to the old address.

The practical solution is an entity mapping document: for each entity (Account, Product, Order, Invoice), specify the source of truth, the synchronization direction (unidirectional or bidirectional), and the required update frequency. When genuine bidirectional synchronization is needed—for example, a payment status update returning from the ERP to the Opportunity record—an explicit rule for conflict resolution is established, such as "the last update by timestamp wins" or "financial fields are always dictated by ERP."

|Entity|Source of Truth|Synchronization Direction|Typical Frequency|
|---|---|---|---|
|Account|Salesforce|Bidirectional with Conflict Rule|Near Real-time|
|Product & Price Book|ERP|Unidirectional to Salesforce|Daily or on Change|
|Order|Created in Salesforce, Managed in ERP|Bidirectional, Separate Stages|Immediate at Creation Stage|
|Invoice & Payment|ERP|Unidirectional to Salesforce|Daily or Near Real-time|
|Available Inventory|ERP|Unidirectional to Salesforce|Every few minutes to Hourly|

## Synchronization Patterns: Request-Reply, Batch, and Event-Driven

Three patterns cover most real-world scenarios. **Request-Reply (synchronous)** is suitable when a Salesforce user waits for an immediate response—for example, checking inventory availability before confirming an order. The advantage is simplicity and immediate feedback; the disadvantage is complete reliance on ERP availability at that moment, and a negative impact on user experience if the response is slow.

**Batch** is suitable for large-volume updates that aren't time-sensitive, such as a nightly price book synchronization or importing invoices from the previous day. This pattern is more resilient to temporary failures, but it implies a latency of hours to a day between systems—a gap that must be acceptable to the business, not just the technical team.

**Event-Driven** (using Platform Events, Change Data Capture, or an external message queue) is appropriate when near real-time response is needed without requiring synchronous dependency. An order status change in the ERP broadcasts an event, and Salesforce updates itself when ready—including automatic retry if it was temporarily unavailable. This is the most flexible pattern, but also the most complex to set up and monitor.

### Pattern Selection Table by Scenario

|Scenario|Recommended Pattern|Typical Latency|Primary Risk|
|---|---|---|---|
|Check Inventory Before Order Confirmation|Request-Reply|Few seconds|Full dependence on ERP availability; Timeout harms user experience|
|Price Book & Product Synchronization|Nightly Batch|Hours to 24 hours|Outdated data between runs; requires coordination with campaigns and promotions|
|Payment Status Update|Event-Driven|Seconds to minutes|Operational complexity; requires monitoring message queue and Dead Letter Queue|
|Create New Order in ERP|Request-Reply with Retry|Seconds to a minute|Partial failure - order created in ERP but response lost, high risk of duplication|
|Update Available Inventory for Sale|Frequent Batch (every 15-60 minutes)|Minutes|Selling based on inventory already depleted between runs|
|Credit Limit Exceeded Alert|Event-Driven|Near Real-time|Lost event results in approval of a transaction that shouldn't have happened|

In this context, the decision on synchronization type is also linked to the permissions model and data ownership—an expansion of this is presented in [Salesforce Sharing and Visibility](/en/insights/salesforce-sharing-visibility-design).

## Middleware vs. Point-to-Point

When there's only one connection between Salesforce and ERP, a direct (Point-to-Point) connection using REST API or Named Credentials might be the quickest and cheapest solution. The problem begins when a third system is introduced—a data warehouse, shipping system, or payment platform—and then each new system requires building its own transformation logic and error handling, duplicating what already exists in the previous connection.

A Middleware layer (such as MuleSoft, Boomi, or Workato) solves this by centralizing the logic: each system connects once to the Middleware, and the Middleware is responsible for transformation, retries, message queues, and centralized monitoring. The cost is an additional infrastructure component that requires licensing, maintenance, and specialized expertise.

A practical rule of thumb: up to two-three stable connections without complex logic—Point-to-Point is reasonable. From three systems upwards, or when there is a central Governance requirement (like uniform monitoring for all integrations in the organization), the cost of Middleware is almost always justified within one to two years.

## Error Handling and Idempotency

The most dangerous scenario in integration is not a complete failure but a **partial failure**: the message was sent, the ERP created an order, but the response to Salesforce was lost due to a timeout. If the sending system naively retries, a duplicate order is created.

The solution is an Idempotency Key—a unique identifier generated on the sending side and attached to each request. The receiving side keeps a record of identifiers that have already been processed and refuses (or returns the existing result) if the identifier already exists. Other practical principles:

- Every critical integration gets a Retry mechanism with gradual Backoff, not immediate and repeated attempts
- Messages that repeatedly fail go to a Dead Letter Queue for manual review, rather than silently disappearing
- Error logs include the full Payload of the failed message to allow manual reconstruction
- A daily or weekly Reconciliation process compares systems and identifies discrepancies that the Sync "missed"

Without an Idempotency Key and a structured Reconciliation process, every transient network problem becomes a persistent data issue that is difficult to trace weeks later.

## API Limits, Security, and Monitoring

Salesforce imposes daily limits on the number of API calls (depending on license and edition), and limits on response size and execution time. An organization synchronizing tens of thousands of records a day via standard REST, call by call, will hit the limit quickly. The solution is Bulk API 2.0 for volume updates, and Composite API to reduce the number of calls in multi-step synchronous processes.

On the security side, three principles recur in every successful project:

1. Use Named Credentials and Connected Apps with OAuth, not fixed usernames and passwords in code
2. The authorization of the integration's "technical user" is strictly limited to the objects and fields it needs—not an Administrator Profile
3. Sensitive traffic (credit card numbers, bank account details) goes through a Middleware layer or Tokenization, not stored as plain text in Salesforce

For monitoring, a Dashboard should be set up that displays at least three metrics: the success rate of messages versus failures, average and median response time, and the number of records in the Dead Letter Queue. An automatic alert when the failure rate crosses a defined threshold (e.g., above 2% of messages per day) prevents an accumulating problem from being discovered only when a customer complains.

These decisions often rely on previous foundational work in information and permissions, described in [Salesforce Technical Debt](/en/insights/salesforce-flow-apex-technical-debt).

## Recommended Workflow

### 1. Map Entities and Define Source of Truth

For each entity (customer, product, order, invoice), determine which system is authoritative in case of conflict. Without this decision, any discussion about "the right way to sync" takes place in a fog.

### 2. Choose a Synchronization Pattern Based on Actual Required Latency

Not every process needs an immediate response. Inventory checks before a sale do; nightly price book updates do not. Matching the pattern to the actual need saves unnecessary infrastructure costs.

### 3. Decide Between Middleware and Point-to-Point

The decision depends on the number of connected systems and the need for central Governance, not purely on technological preference.

### 4. Plan Idempotency, Retry, and Reconciliation from the Start

These are not "future enhancements" but part of the Definition of Done for any integration involving money, inventory, or orders.

### 5. Define Minimum Permissions for the Technical User

A dedicated Profile, not a sweeping administrator permission. Any permission change requires separate approval from functional changes.

### 6. Test Failure Scenarios, Not Just Happy Path

Running a test where the ERP "crashes" mid-process and measuring recovery time and whether duplicates are created, uncovers problems not visible in a quiet development environment.

### 7. Set Up a Dashboard and a Regular Reconciliation Process

Technical monitoring (is the server alive) is not enough; business monitoring (are order counts equal in both systems) is needed.

## Example Organizational Scenario

A trading company with approximately 40,000 orders per month connected Salesforce to its ERP using direct synchronous REST calls, without Middleware. During a peak sales period, the failure rate for API calls sharply increased due to the daily call limit, and orders that failed to register in the ERP simply "disappeared"—because there was no Dead Letter Queue and no alert.

After investigation, three things were found missing: no Idempotency Key was defined, so retries sometimes created duplicate orders; there was no use of Bulk API for volume updates; and there was no Reconciliation process comparing order counts between the two systems. The solution involved transitioning to a Middleware layer with a message queue, replacing some synchronous calls with frequent Batches, and adding a daily Dashboard displaying discrepancies.

The result wasn't "zero faults"—that's an unrealistic goal—but rather a fault identification time that dropped from weeks to hours, and a process that allows fixing discrepancies the same day, rather than after a customer complains.

## Common Risks and Preventive Actions

|Risk|How it Appears in Practice|Preventive Action|
|---|---|---|
|No Defined Source of Truth|Two "correct" sources simultaneously, and no one knows which to trust|Entity mapping document with defined owner for each critical field|
|Lack of Idempotency|Duplicate orders after every transient network failure|Idempotency Key and duplicate check on the receiving side|
|Point-to-Point Without Governance|Any change in one system silently breaks other connections|Middleware layer, documented contracts, and clear ownership|
|Ignoring API Limits|Calls fail during peak load, without early warning|Transition to Bulk API, monitor daily quota consumption|
|Broad Permissions for Technical User|Exposure of sensitive information beyond integration needs|Limited Profile and periodic permission review|

Those at an earlier stage than connection planning may find complementary background in [Salesforce Flow or Apex](/en/insights/salesforce-flow-vs-apex), primarily in deciding where the transformation logic actually resides.

## How to Measure Success

|Area|What to Measure|Inspection Frequency|
|---|---|---|
|Reliability|Rate of completed vs. failed messages|Continuous, with alert on threshold breach|
|Latency|End-to-end time for each scenario separately|Continuous|
|Data Consistency|Number of discrepancies in Reconciliation check|Daily or Weekly|
|Operational Cost|Support hours dedicated to integration issues|Monthly|

It's advisable to choose only three to four metrics for the first version, and to measure them before launch to have a true Baseline for comparison, not an estimate from memory.

## Pre-Production Checklist

- ☐ For each entity, a single source of truth and a conflict resolution rule are defined
- ☐ A synchronization pattern (Request-Reply, Batch, or Event-Driven) is chosen for each process separately
- ☐ It has been decided whether Middleware is needed or if a direct connection is sufficient
- ☐ An Idempotency Key exists for every operation that creates a financial record
- ☐ Retry with Backoff and a Dead Letter Queue are defined for failed messages
- ☐ Daily API quota consumption has been checked against expected volume
- ☐ The technical user's permissions are limited to the required objects and fields only
- ☐ Partial failure testing has been performed, not just happy path
- ☐ A Dashboard exists for business monitoring, not just technical
- ☐ A regular Reconciliation process is defined and owned

## In-Depth Notes for Implementation and Maintenance

### Architect's Note: When to Change an Existing Pattern

If a nightly Batch pattern was initially chosen for simplicity but the business starts demanding near real-time inventory updates, there's no need to "blow up" the entire architecture—you can increase frequency to 15 minutes as an interim step, and only transition to Event-Driven when it becomes clear that even that isn't enough. Gradual change, accompanied by actual latency measurement, is preferable to a blanket decision made too early.

From a management perspective, the true test of a Salesforce-ERP connection is not just that it "works today," but that you can explain within five minutes why each pattern was chosen, and who is responsible for fixing it when something goes wrong. A solution that requires lengthy investigation for every issue creates a hidden operational cost that grows over time.

Where internal capacity for planning or implementing such a connection is lacking, [CRM Architecture Services](/en/crm-architecture) is the practical path forward.

## Professional Resources

- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data

### Questions and answers
**What do you do when ERP and Salesforce disagree on a customer's status?**
First, establish which system is the 'single source of truth' for that specific entity. Typically, ERP handles billing and inventory, while Salesforce manages customer relationships. Then, implement a daily reconciliation rule to highlight discrepancies, rather than assuming a 'green' sync means data is truly consistent.

**When is Point-to-Point integration sufficient, and when is Middleware essential?**
For up to two or three stable integrations, Point-to-Point might suffice. However, once you involve three or more systems, require shared transformation logic, or need centralized retry mechanisms and monitoring, a Middleware layer like MuleSoft saves you from maintaining multiple versions of the same logic across different systems.

**How do you maintain Idempotency when a message is sent twice?**
Each message receives a unique identifier (Idempotency Key). The receiving system checks if this key has already been processed before creating a new record. This is typically stored in a dedicated external field on the record or in a separate log table, ensuring that duplicate processing doesn't lead to a duplicate order.

**What happens when you hit Salesforce's daily API call limit?**
You need to shift from frequent synchronous calls to bulk processing (Bulk API) or reduce polling frequency. Organizations with tens of thousands of order updates per day will almost certainly hit limits if they rely on standard REST APIs instead of Bulk API 2.0.

**How do you test an ERP integration before it goes live?**
Build a Staging environment with representative data, execute a full scenario including partial failures (e.g., ERP downtime, corrupted message, duplicates), and measure the time to consistency. Business approval should only be granted after failure scenarios have been demonstrated, not just the 'happy path.'

---

## Salesforce Data Migration: The Complete Guide to Planning, Cleaning & Cutover
URL: https://hpi.pro/en/insights/salesforce-data-migration-guide
Most migration pitfalls aren't tool-related, but rather stem from incorrect load order, rushed field mapping, and lack of reconciliation. This guide builds a comprehensive process: profiling, cleansing, external IDs, dry runs, and post-go-live remediation.

## The Short Answer

Salesforce data migrations commonly fail, not due to the tools themselves, but because of flawed processes. This includes starting data loads before understanding source quality, field mappings developed in isolated Excel sheets without anomaly checks, and loads that disregard object dependencies. A proper process is built as an iterative cycle: profiling, mapping, cleansing, controlled loading, testing, and reconciliation—and only then, cutover.

This article aims to break down the migration lifecycle into clear stages, providing a data load order table and a reconciliation checklist that can be used effectively. In most projects, the difference between a smooth migration and one that leads to rework is decided in the first week, during the source profiling phase.

Early data cleansing work prevents later damage, and it's highly recommended to read more on this at [Salesforce Data Deduplication](/en/insights/salesforce-data-deduplication).

## Source Profiling: Understand the Data Before Touching It

Before mapping a single field, you must profile the source data: How many records are in each table? Which fields are actually empty (not just in the schema but within the data itself)? What is the range of values in numeric and date fields? Where are free-text values that should be closed lists? In one project we oversaw, a "Client Status" field had 47 different formulations in the source—"Active", "", "Active " with a space, ""—all of which should have mapped to a single value in Salesforce.

Tools like OpenRefine, simple SQL queries, or even an Excel Pivot Table on a data sample are sufficient for most projects. The goal is to generate a profiling document that shows: total record count, percentage of empty required fields, number of unique values for each categorical field, and initial identification of potential duplicates by name, phone, or email.

This stage also identifies if there are multiple overlapping data sources—for example, the same customer existing in both an old CRM and an accounting system—and decides which source is the "Source of Truth" for each field. Such a decision must be documented, not assumed, as it impacts every subsequent stage.

## Field Mapping: Beyond the Excel Sheet

Good field mapping isn't just "source column A = target field B." It also includes transformation directions: date format conversion, unit conversions, splitting a single address field into street/city/zip, and a solution for values not present in the target's picklist. The best mapping document we've seen included five columns: Source Field, Target Field, Transformation Type, Rule for Handling Missing Value, and Input/Output Example.

Special attention must be paid to Lookup and Master-Detail fields: they don't contain a direct value but a reference to another record. Therefore, their mapping depends on the linked record already having been loaded and holding an ID that can be referenced. This is why load order (discussed next) and field mapping are two sides of the same decision.

For a broader context on managing field quality over time, not just in a one-off phase, see [Salesforce Data Quality Metrics](/en/insights/salesforce-data-quality-metrics).

## Cleansing and Duplicates: Before Loading, Not After

Cleansing data after it's already in the production environment is exponentially more expensive: it involves updating live records, risking broken automations and approval processes, and sometimes compromising reports already distributed to management. Therefore, the cleansing phase must occur in the staging layer before data enters Salesforce.

Key cleansing rules to define in advance:

- Normalization of phone and email (removing spaces, consistent international format)
- Identification of duplicates by combining fields (name + phone, or company ID only for businesses)
- Rule for selecting the Master record when merging duplicates—for example, the most recently updated or most complete record
- Handling Null values versus empty strings, to avoid "phantom duplicates"

In a typical project with about 80,000 customer records, reasonable cleansing will identify between 3% and 8% true duplicates. A significantly higher number suggests the source itself was not maintained, and warrants a discussion with business process owners before proceeding.

## External IDs and Load Order

An External ID is a unique identifier from the source system that is also stored in Salesforce, allowing for repeated loading (Upsert) without creating duplicates every time a file is re-run. Without an External ID, every subsequent Data Loader run might create another copy of the same record because the system cannot "recognize" an existing record.

The load order is determined by object dependencies: you cannot load a Contact before the Account it's associated with exists, and you cannot load an Order Item before the Order itself.

| Stage | Object | Dependency | External ID Note |
| --- | --- | --- | --- |
| 1 | Account | No Dependency | Customer ID from source system (ERP/old CRM) |
| 2 | Contact | Depends on Account | Contact ID + Lookup to Account External ID |
| 3 | Opportunity | Depends on Account, Contact | Opportunity ID from source system |
| 4 | Product / PriceBook Entry | No Dependency (loads in parallel with stages 1-2) | SKU as External ID |
| 5 | Opportunity Line Item | Depends on Opportunity, Product | Combination of Opportunity ID + Line Item |
| 6 | Case / Activity History | Depends on Account, Contact | Case ID from source system |

Deviating from this order is one of the most common errors in migration projects: teams trying to "save time" by loading all files concurrently later discover thousands of Lookup errors that are difficult to sift through afterward, because it's unclear if the error is due to missing data or an incorrect load order.

For more on managing field quality over time, not just in a one-off phase, refer to [Salesforce Data Quality Metrics](/en/insights/salesforce-data-quality-metrics).

## Environments and Testing

A migration is never loaded directly into production. A recommended environment structure includes a dedicated Sandbox for migration (separate from ongoing development Sandboxes), where the same data volume and the same configuration of Validation Rules and Triggers as in production are loaded, to expose issues before they impact real users.

Testing at this stage includes volume testing (does the load complete within a reasonable timeframe), error testing (what percentage of records are rejected and why), and automation behavior testing—a Flow or Trigger that runs on record creation could send a real email to a customer if not temporarily deactivated in the test environment. Forgetting such a detail in one project resulted in thousands of duplicate "welcome" emails being sent to existing customers.

## Dry Run: A Full Rehearsal

A Dry Run is a full execution of the loading process under conditions as close as possible to production—same volume, same files, same order—but in a Sandbox environment. The goal is to measure two things: actual execution time (to plan the cutover window realistically) and the percentage of errors at each stage.

It's recommended to perform at least two full Dry Runs: the first often uncovers most issues, the second verifies that the fixes actually resolved them and didn't introduce new problems. If a second run still yields more than 1%-2% errors in critical objects, it's usually better to postpone the cutover date than to compromise on quality.

## Cutover and Data Reconciliation

Cutover is the actual window during which the old system is frozen, the latest information is loaded into Salesforce, and users transition to working in the new system. Success at this stage is measured not just by "did the load complete?" but by reconciliation—a systematic comparison between the source and target.

A reconciliation checklist to run at the end of each cutover:

- ☐ Record counts are identical (or explained by a known discrepancy) in every key object
- ☐ Sums of financial fields (e.g., total value of open opportunities) match between sources
- ☐ A random sample of 30-50 records is manually checked field-by-field
- ☐ Relationship checks—does every Contact have a valid Account, every Opportunity Line Item an Opportunity
- ☐ Check for "orphan" records—loaded without a valid reference
- ☐ Comparison of duplicate counts before and after against the target set during the cleansing phase
- ☐ Business process owner approval that their data sample appears correct

Common reconciliation discrepancies include: matching record counts but incorrect sums, because a numeric field was loaded in the wrong format; or missing relationships because a Lookup was loaded by text value instead of External ID. Full documentation of the reconciliation process, including a baseline example, is also found in [Salesforce Master Data Management](/en/insights/salesforce-master-data-management).

## Post-Go-Live Fixes

Even a successful cutover leaves a "tail" of fixes: individual records rejected during the load, users reporting missing data, and discrepancies that only emerge when real users work with the system, not just test it. A two- to four-week window for targeted fixes should be allocated in advance, with a daily exception report in the first week and weekly afterward.

It's important to distinguish between a specific fix (a single record updated manually) and a systemic fix (a mapping error that recurs across thousands of records and requires a fix in the loading tool itself and a re-run). Confusing the two causes teams to manually fix a problem that is actually systemic, wasting significant time.

## Example Organizational Scenario

A distribution company with approximately 120,000 customers in an old CRM and a separate customer list in the accounting system wanted to migrate both sources to a single Salesforce instance. Initial profiling revealed that 11% of customers appeared in both sources with different contact details, and the "Industry" field contained 340 free-text values that should have been about 25 categories.

The team built detailed field mapping, established a merge rule based on a combination of company ID and phone, and designated the accounting system as the Source of Truth for billing details and the old CRM as the Source of Truth for contact information. The first Dry Run revealed that 4% of records were rejected due to invalid date formats—a fix that was accounted for in the second run. Cutover was performed over a weekend, with full reconciliation on Monday morning before opening the system to users.

The result: less than 0.3% of records required manual correction after Go Live, compared to the team's initial estimate of about 5% exceptions. The difference was almost entirely due to the two Dry Runs performed before the official date.

## Common Risks and Prevention Actions

| Risk | How it Appears in Practice | Prevention Action |
| --- | --- | --- |
| Ununified Identities | Same customer initiates duplicate processes | Unification rule by External ID and Golden Record |
| Loading without External ID | Re-running creates new duplicates | Define External ID before the first run |
| Incorrect Load Order | Massive Lookup errors difficult to filter | Load according to a predefined dependency table |
| Skipping Dry Run | Cutover window extends, surprises emerge in real-time | At least two full runs in a testing environment |
| No Reconciliation | Correct record counts but incorrect sums and relationships | Count, sum, relationship, and sampling checks at each Cutover |

At the management level of a Salesforce data migration, this risk table is just a starting point. An expansion on continuous quality management, including the difference between one-time cleansing and ongoing data governance, is covered in [Data 360 Zero Copy](/en/insights/data-360-zero-copy-federation).

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Completeness | Rate of required fields and critical information filled | Before and after each load |
| Uniqueness | Rate of duplicates per entity | Before Dry Run and after Cutover |
| Validity | Values conforming to format and business rules | With each loading batch |
| Reconciliation | Alignment of counts, sums, and relationships to source | At each Rehearsal and Cutover |
| Execution Time | Actual loading duration vs. planned Cutover window | At each Dry Run |

For most projects, three to five metrics are sufficient for the first version. A good metric can be calculated before and after the change, is relevant to the business process owner, and cannot be artificially improved by partial data entry. When no documented baseline exists from the old system, it's worth spending a day or two measuring the current state before reporting improvements.

## Checklist Before Go Live

- ☐ Source profiling performed and includes percentages of empty and duplicate fields
- ☐ Full field mapping document, including transformations and handling of missing values
- ☐ External ID defined for every object requiring re-loading
- ☐ Written load order agreed upon by the technical team
- ☐ Two Dry Runs performed and errors reduced below the defined threshold
- ☐ Written rollback scenario in case the Cutover fails
- ☐ Reconciliation Checklist ready and the person responsible for it is known in advance
- ☐ A post-Go Live fix window allocated in the schedule
- ☐ Automations that could send communications to customers checked and deactivated during the load
- ☐ Business process owner signed off on a final data sample

## In-Depth Notes for Implementation and Maintenance

### Architect's Note: Migration Is Not a One-Time Event

Even after a successful Go Live, changes in the source system (if it continues to operate temporarily in parallel) or manual corrections will create data discrepancies. Therefore, it is advisable to maintain a regular reconciliation report—weekly in the first month, then monthly—that compares a data sample between old and new reports and identifies deviations early. A project that treats migration as a finish line misses the fact that data quality is an ongoing process.

From a management perspective, the true test of a Salesforce data migration is not just whether the records were loaded, but whether Data, CRM, and project managers can trust the reports the day after, without manually checking every number. Organizations seeking professional guidance for such a process can leverage [Integration and Data Services](/en/integrations-data), which supports both the planning phase and the cutover window itself.

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**How far in advance of Cutover should the first Dry Run be performed?**
It's recommended to conduct a full Dry Run at least three to four weeks before the Go-Live date, with a second run one to two weeks prior. This provides ample time to address exceptions, measure actual load duration, and ensure the allocated cutover window is sufficient, with a buffer.

**What's the best approach when duplicate customer records are discovered after the system is live?**
Run a consolidation rule based on a business identifier (e.g., normalized EIN or email), select a Master record based on recency and data completeness, and merge using a dedicated Merge tool or a controlled process that updates relationships before deleting duplicates. Full backup is essential before executing such an operation.

**Can we skip External IDs and rely solely on names for record matching?**
Not advisable. Names are often duplicated, vary across systems, and can contain different spaces or characters. A unique External ID from the source system ensures unambiguous mapping, enables repeated loads (Upsert) without duplicates, and significantly reduces troubleshooting time.

**What's the correct load order when a single file contains all record types mixed together?**
You should split the file by object. Load independent entities first (Accounts), then dependent entities (Contacts, Opportunities), and finally relationships and detail items. A mixed load without proper order will generate Lookup errors and orphaned records that are difficult to trace retrospectively.

**How much time should be allocated for post-Go-Live remediation before closing the project?**
For a medium-sized migration project, it's recommended to allocate two to four weeks of close monitoring. During this period, daily exception reports, reconciliation discrepancies, and user complaints should be reviewed. Only after two clean reporting cycles (two weeks) can the remediation phase be declared closed.

---

## Agentforce for Business: When It Works, When It Doesn't (Yet)
URL: https://hpi.pro/en/insights/agentforce-for-enterprises
Not every process is ripe for an autonomous AI agent. This guide establishes an operational decision framework – covering data maturity, grounding, permissions, and Human-in-the-Loop – to differentiate use cases ready for Agentforce from those better suited for classic automation.

## The Short Answer

Implementing Agentforce for organizations isn't a question of "can Salesforce support this," but rather one of maturity. Key questions include: Is there a reliable source of truth? Is it clear who authorizes sensitive actions? What baseline will differentiate success from failure? Organizations that bypass these questions and rush directly to building an agent will discover the gap in the second month when costs rise and results become inconsistent. The correct approach begins by filtering processes, continues with data and permission readiness checks, and concludes with a measured pilot featuring clear go/no-go criteria.

Those still establishing a foundational understanding can start with [Agentforce Readiness](/en/insights/agentforce-salesforce-ai-guide), which explains the differences between Copilot, Flow, and Agentforce itself.

## Six Readiness Focus Areas

Before selecting an initial use case, it's worthwhile to map out your organization against six key areas. Any area remaining at an "unknown" level represents a risk that will surface during the pilot, rather than being identified beforehand.

| Readiness Area | Core Question | Common Warning Sign |
| --- | --- | --- |
| Data and Knowledge Maturity | Is there a single, updated, and approved source of information? | Outdated Knowledge Base, conflicting documents |
| Grounding | Does the agent retrieve real information or guess? | Convincing but factually incorrect answers |
| Topics and Actions | Is each Topic defined within narrow boundaries? | A single agent expected to "answer everything" |
| Permissions and Security | Does the agent operate according to the actual user's permissions? | System permission returning information to anyone |
| Human-in-the-loop | Who approves an irreversible action? | Financial or legal action without oversight |
| Measurement and Cost | Is there a baseline for comparison? | "It looks impressive" without a quantifiable metric |

### Data and Knowledge Maturity

An effective AI agent is only as good as the information it’s fed. In a service organization with three unsynchronized Knowledge systems, the agent will learn from the first source it encounters—even if it's the least accurate. Before any technical work, it's crucial to check: when was each document last updated, who owns it, and what happens if there are two conflicting documents? Organizations that skip this step often launch a pilot with an agent that generates confident yet incorrect answers, which is worse than "I don't know."

### Grounding

Grounding is the search mechanism that feeds an agent actual information before it formulates a response, rather than relying on the model's general knowledge. The depth of this topic, including considerations for Chunking, Vector Search, and the separation of internal and external sources, is detailed in [Agentforce Grounding](/en/insights/agentforce-grounding-rag). At a management decision level, it's sufficient to understand that without solid Grounding, all other investments—conversation design, Actions, and interface—are built on a shaky foundation.

### Topics and Actions

The most common mistake is building a single agent with a broad Topic like "customer service" instead of several narrow Topics such as "order status inquiry" or "update billing details." A narrow Topic is easier to test, easier to explain to the user why the agent didn't answer, and easier to gradually add Actions to. An Action itself should operate under limited permissions, undergo input validation, and return a clear error when something doesn't match—rather than guessing.

<h3>Permissions and Security</h3>

An agent operating under broad integration permissions risks exposing information that the interacting user shouldn't see—like another employee's salary, another customer's order, or a sensitive internal note. The professional recommendation is to run the agent under the actual user's permission context (Run As User) wherever possible, and to document any deviation from this model as a conscious decision with an explicit owner.

### Human-in-the-loop

Not every action requires human approval, but every irreversible action does. Issuing a refund, canceling an order, changing access permissions—these are areas where it's better to let the agent prepare the action and pause before execution, at least in the initial months. Over time, as metrics demonstrate high accuracy for a specific subset, approval can be phased out gradually rather than all at once.

### Measurement and Cost

The cost of Agentforce isn't just licensing; it includes tokens, API calls, and monitoring infrastructure. The full financial discussion, including pricing examples and scaling scenarios, can be found in [Agentforce Cost (TCO)](/en/insights/agentforce-cost-tco). Without a baseline of "how long it currently takes a representative to complete this task," it’s impossible to know if the agent is saving money or merely adding a layer of complexity.

## Fit or No-Fit Table

While this table doesn't replace in-depth analysis, it serves as a quick screening tool before investing weeks into evaluating a use case that may not mature.

| Use Case | Fit | Reason |
| --- | --- | --- |
| Answering FAQs from an updated Knowledge Base | High Fit | Structured information, low risk, measurable improvement in response time |
| Checking order status and updating shipping details | High Fit | Closed data in system, simple Action, easy to verify |
| Complex multi-year sales trend analysis | Partial Fit | Requires deep business context; suitable only for advanced stages |
| Approving credit or changing contract terms | No-Fit in initial stage | High financial impact, requires constant Human Approval |
| Medical, legal, or regulatory advice for end-customers | No-Fit | Litigation and liability risk; requires full human oversight |
| Drafting marketing content for human review | High Fit | Output is not final, human always reviews before publication |

## Realistic Pilot Plan

### Step 1: Select a Single Use Case (Week 1)

Choose one high-fit process from the table, define a baseline (average handling time, current escalation rate), and document what constitutes success. A business sponsor must sign off on the scope.

### Step 2: Build Grounding and First Topic (Weeks 2-3)

Connect a single, authenticated information source, build a narrow Topic with no more than 2-3 Actions, and define permissions based on the user. Each Action undergoes invalid input testing before being considered ready.

### Step 3: Controlled Internal Rollout (Weeks 4-5)

A small group of users (5-15 individuals) tests the agent in real-world scenarios, including Human Approval for all significant actions. Traces and incidents are collected by severity.

### Step 4: Measure Against Baseline (Weeks 6-8)

Compare handling time, success rate, and cost against the initial phase. This is where the Go/No-Go criteria apply:

- **Go**: Task completion rate without escalation above 70%, cost per task lower than human alternative, zero security or permission incidents
- **Gradual Expansion**: Completion rate 50-70% - continue but narrow the scope to a sub-task that performed better
- **No-Go**: Completion rate below 50%, or a single permission incident - revert to the data and permissions phase before any expansion

More comprehensive testing, including an automated Scorers methodology, is described in [Agentforce Testing](/en/insights/agentforce-testing-scorers).

## Example Organizational Scenario

A service company with a 40-agent call center wanted to implement Agentforce to reduce workload. Management requested "an agent that answers everything." A readiness assessment revealed three unsynchronized Knowledge bases, and most inquiries required access to sensitive billing data. Instead of starting broadly, the team chose a single use case: order status inquiry, which does not require sensitive financial data.

Within six weeks, the agent handled 62% of these inquiries without escalation, at a significantly lower cost than a minute of human agent talk time. According to the Go criterion, the company gradually expanded to a second Topic—updating shipping addresses—and only then began to explore financial actions, with constant Human Approval. This gradual approach prevented a complete failure that would have occurred had the organization gone straight for "an agent that knows everything."

## Common Risks and Prevention Actions

| Risk | How it Appears in Practice | Prevention Action |
| --- | --- | --- |
| Overly broad Use Case | Unable to measure success or predict behavior | Start with a single narrow process with clear boundaries |
| Weak Grounding | Confident but factually incorrect answers | Single information source, owner, and regular update process |
| Overly broad Permissions | Agent exposes information the user shouldn't see | Run under user context, not system permission |
| Skipping Human Approval | Financial or legal action taken without oversight | Mandatory human approval for all irreversible actions |
| Absence of Baseline | "It seems to be working" without numerical proof | Measure current state before launch, not after |

## How to Know When It's Time to Expand

Expansion is justified when three conditions are met simultaneously: the main metric is stable over three consecutive measurement cycles, there are no permission or security incidents during the measured period, and the process owner is willing to sign off that the result is equivalent to or better than the human alternative. If any of these conditions are missing, it's better to extend the pilot phase by an additional two weeks than to expand based on a good feeling.

## Pre-Decision Checklist

- ☐ A single use case with clear boundaries has been selected, not a "general agent"
- ☐ An authenticated and updated information source exists for the chosen area
- ☐ Agent permissions align with the actual user's permissions
- ☐ Human Approval points have been defined for irreversible actions
- ☐ A baseline was measured before launch, not just after
- ☐ Go/No-Go criteria are documented in advance
- ☐ A plan for monitoring traces and incidents exists
- ☐ An owner is designated as responsible for information source maintenance

## Summary: When to Proceed and When Not To

Agentforce is suitable when there is a narrow process with a reliable information source, the impact of an error is relatively low, and there's a way to measure success against a real baseline. It's less suitable—at least initially—for processes with high financial or legal impact, for organizations where information is still scattered and unmaintained, or when management expects immediate results without a pilot phase. Organizations that respect this order of operations—first readiness, then a measured pilot, and only then expansion—achieve a much more stable outcome than those who jump straight to development. Actual implementation can be run with [Agentforce & AI Services](/en/agentforce-ai), which guides the organization from the compatibility check phase through controlled expansion.

## Professional Resources

- Salesforce – How Agentforce Works — https://www.salesforce.com/agentforce/how-it-works/
- Salesforce – Agentforce Guardrails — https://help.salesforce.com/s/articleView?id=ai.agent_plan_risks_guardrails.htm&language=en_US&type=5
- Salesforce – Agent Testing Custom Scorers — https://developer.salesforce.com/docs/ai/agentforce/guide/testing-api-custom-scorers.html
- HPI Pro – Agentforce & AI — https://hpi.pro/agentforce-ai

### Questions and answers
**What's the difference between a suitable Agentforce use case and one better built as a standard Flow?**
A suitable agent use case requires real-time judgment – choosing between multiple paths based on natural language or changing context. If the process always follows a fixed, predictable sequence, Flows or Apex are more cost-effective, fully testable, and don't require monitoring traces.

**How much documented data is needed before starting an Agentforce pilot?**
Perfect documentation isn't required, but you do need a clear single source of truth for at least one domain: up-to-date Knowledge articles, accurate CRM fields, or approved policy documents. If 30% of answers require human intervention due to missing or conflicting information, the pilot will fail because of data, not the agent.

**Can Agentforce operate without any human approval?**
Yes, for low-risk actions like retrieving information or updating non-sensitive fields. For any action impacting finances, permissions, external customers, or irreversible data, a human approval step is recommended, especially for the first 3 months post-launch.

**How do you measure an agent's actual ROI, not just theoretical benefits?**
During a 6-8 week pilot, build a dashboard showing token and infrastructure costs versus the number of tasks completed without escalation. If the task's cost exceeds the savings – e.g., an hour of an agent's work – the agent isn't ready for rollout, even if it 'works'.

**What happens if the pilot fails the Go/No-Go criteria?**
Don't scrap the project – narrow the scope. Failure is often due to weak grounding or an overly broad use case, not the technology itself. Break the process into one narrow sub-task, fix the data source, and re-test before investing in further expansion.

---

## 15 Critical Questions Before Choosing a Salesforce Integrator
URL: https://hpi.pro/en/insights/questions-before-choosing-salesforce-integrator
On paper, most Salesforce proposals look alike until you dig deeper with these 15 targeted questions. This guide breaks them down into six key areas—from team dynamics to business continuity—illustrating the difference between a weak response and one you can trust.

## The Short Answer

Proposals from different Salesforce integrators almost always look similar. They use the same buzzwords like Discovery, Agile, Best Practice, and promise "close support." The real difference only emerges when you evaluate each proposal against concrete questions that reveal how the vendor thinks, not just what they propose to deliver. The purpose of the following 15 questions is to identify gaps *before* signing, not after the project is already stuck.

The questions are divided into six topics: Team, Methodology, Architecture, Data, Commercial Terms, and Continuity. Each question includes a short explanation of why it's important and a description of what a weak answer sounds like—making it easy to identify in real-time, whether in a meeting or a proposal document.

We've detailed the practical implications of selection on the entire implementation process separately in [Choosing a Salesforce Implementation Company](/en/insights/choose-salesforce-implementation-company).

## Why 15 Questions and Not a Technical Requirements List

A technical requirements list—how many Sandboxes, what licenses, SLA times—is important but insufficient. It checks what the vendor *says* they will do, not how they will handle situations where the original plan turns out to be inaccurate. The questions here were chosen because they reveal working patterns: how the team documents decisions, how it handles dirty data, and what happens when something doesn't go according to plan.

## Summary Table: Strong vs. Weak Answer

| Topic | A strong answer sounds like this | A weak answer sounds like this |
| --- | --- | --- |
| Team | "Consultant X leads architecture, developer Y executes; we'll share CVs and allow a brief interview." | "We have an experienced team; we'll assign the right people during Kickoff." |
| Methodology | "Two-week sprints, a real demo at the end of each sprint, shared backlog in Jira." | "We work Agile; it's flexible and suitable for any project." |
| Architecture | "We'll build an ADR for every key decision, including rejected alternatives and reasons." | "We'll choose the best solution based on our experience." |
| Data | "We'll run Data Profiling before the final proposal, and clarify the quality of your sources." | "We'll handle data cleaning during development." |
| Commercial | "Fixed price for a defined Scope, additional hours per documented Change Request." | "Flexible T&M to avoid limiting you." |
| Continuity | "Handover document, internal Admin training, two weeks of Hypercare after Go Live." | "We're always here for you; no need for a separation protocol." |

## Team: Who Will Actually Work on the Project

### 1. Who will actually support the project, not just in the proposal?

This question is critical because many proposals feature senior team members in sales meetings but replace them with junior consultants after signing. A strong answer includes names, roles, and allocated percentage of time. A weak answer sounds like, "We'll choose the most suitable person based on availability"—meaning no genuine allocation until the last minute.

### 2. How many concurrent projects does each consultant manage at the same time?

A consultant managing five projects simultaneously cannot pay attention to detail. A strong answer will acknowledge this limitation and present a reasonable number (typically two to three projects). A weak answer evades or says, "It depends on the workload," without a concrete number.

### 3. What happens if the lead consultant leaves mid-project?

A strong answer describes a documented handover process, a two-week overlap, and ongoing documentation that allows for replacement without knowledge loss. A weak answer claims, "This hardly ever happens with us," without a contingency plan. You can read more about a proper working structure with a [Salesforce Consultant](/en/insights/salesforce-consulting-guide).

## Methodology: How the Work Actually Proceeds

### 4. What does a typical sprint look like—what happens if something isn't ready on time?

A strong answer describes Sprint Planning, a short Daily Scrum, a Demo, and a Retrospective, as well as what happens when a task gets stuck—whether it's transparently deferred to the next sprint. A weak answer merely states, "We work Agile," without detailing any concrete ceremonies.

### 5. What does ongoing communication look like—channel, frequency, and responsible party?

A strong answer specifies a channel (Slack, Teams), a regular weekly status meeting, and a single point of contact for escalation. A weak answer "We'll always be available by email," which in practice means there's no SLA for response.

### 6. How is work tested before it's presented to the client as complete?

A strong answer describes internal QA, an acceptance checklist, and accessibility and permissions testing before a demo. A weak answer implicitly admits that the first client demo is also the first test.

## Architecture: How Decisions Are Made

### 7. How are architectural decisions documented, and who approves them?

A strong answer presents a concise decision template—problem, alternatives, choice, and reason—that is saved and accessible to the client. A weak answer says, "We choose the right solution," without documenting why other alternatives were rejected.

### 8. How will the solution handle load and growth in two to three years?

A strong answer addresses Governor Limits, expected data volume, and scalability planning. A weak answer says, "Salesforce is inherently scalable," without connecting it to the specific use case.

### 9. What happens when a new requirement conflicts with a previous decision?

A strong answer describes a Change Request process that assesses the impact on what's already built. A weak answer simply promises, "We'll adapt to any change," which usually results in accumulating technical debt in the background.

## Data: Where Most Projects Get Stuck

### 10. How is data quality checked before starting to build?

A strong answer includes an early profiling stage—duplicates, empty fields, inconsistent formats—and a timeline for correction. A weak answer defers this to, "We'll handle it during migration," which almost always extends the project.

### 11. What is the source of truth for each data type, and how are redundancies between systems handled?

A strong answer identifies in advance which systems "win" in a conflict (e.g., ERP vs. Salesforce for existing customers) and documents the rule. A weak answer says, "Salesforce will be the source of truth" across the board without checking if this is true for every object.

### 12. What is the backup and recovery plan, and who is responsible for it after implementation?

A strong answer details backup tools, frequency, and who performs recovery in practice if needed. A weak answer assumes Salesforce "already takes care of it" without distinguishing between platform backup and organizational-level backup.

## Commercial and Continuity: What Happens After Signing

### 13. How is the price structured—fixed, T&M, or hybrid, and what is actually included?

A strong answer breaks down the price into workstreams with estimated hours for each and defines what constitutes a Change Request with additional payment. A weak answer gives a single global number without a breakdown, making it difficult to compare proposals.

### 14. What happens if the project runs over time—who absorbs the cost?

A strong answer distinguishes between delays caused by the vendor (at their expense) and delays caused by changes in client requirements (paid by the client). A weak answer uses ambiguous phrasing that allows the vendor to pass any delay costs onto the client.

### 15. What happens at project completion—what support, for how long, and at what rate?

A strong answer includes a defined Hypercare period (typically two to four weeks), a handover document, and internal Admin training. A weak answer promises "ongoing support" without a clear rate, scope, or end date. More on correctly drafting such contract clauses appears in [Salesforce Project SOW Contract Clauses](/en/insights/salesforce-sow-contract-clauses).

## Organizational Case Study

A financial services company received three proposals to merge two old CRM systems into a single Salesforce instance. Two of the proposals were 20%-25% lower in price than the third. When the CIO asked question 10 (early data quality check), the two cheaper vendors replied, "We'll handle it as part of the migration"—while the more expensive vendor presented a one-week profiling plan before the final amount was signed.

The organization chose the more expensive vendor. The one-week profiling revealed about 12,000 duplicate records and a date field in an inconsistent format across 3 data sources. This early correction was included in the original pricing; with the other two vendors, it would have been discovered during migration as a scope change with additional payment.

The lesson here isn't "cheap is always bad"—but that the gap between a detailed answer and a general one is worth real money, and it can only be revealed with targeted questions *before* signing, not afterward.

## Proposal Comparison Checklist

- ☐ We received names and allocated percentages of the proposed team, not just a general description.
- ☐ We checked how architectural decisions are documented by each vendor.
- ☐ We requested a data profiling plan before signing.
- ☐ We broke down the price into workstreams with estimated hours.
- ☐ We clarified who absorbs the cost of delays not attributable to the client.
- ☐ We received an explicit description of the Hypercare period and its terms.
- ☐ We checked references from clients with similar project scopes.
- ☐ We verified that the consultant presented in the meeting is the one who will actually work on the project.
- ☐ We checked how many concurrent projects each lead consultant manages.
- ☐ We defined in advance what evidence will demonstrate project success at completion.

## Concluding Remark: The Questions are a Tool, Not a Ceremony

The purpose of these 15 questions is not to embarrass a vendor or unnecessarily prolong the selection process. It is to reveal in advance where the proposal relies on an unwritten assumption. A good vendor will not be offended by the questions—they will be happy to answer them because it reduces risk for them later. A vendor who evades them, or gives consistently general answers, is thereby providing an answer in itself.

When internal capacity is lacking to run such a comparison process yourself, [Consulting and Discovery services](/en/consulting-discovery) are the practical path forward—including building a weighted scorecard, support in meetings with proposers, and comparing answers against objective criteria.

## Professional Resources

- HPI Pro – Consulting and Discovery — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Services — https://hpi.pro/services

### Questions and answers
**How long does it typically take to thoroughly compare several integrators at this level?**
Allow approximately three to four weeks for a serious evaluation process: one week for joint scope preparation, one to two weeks for meetings and written responses, and one week for comparison and reference checks. A quicker process often relies on first impressions and misses critical gaps in assumptions.

**What if a vendor refuses to provide written answers to some questions?**
This is a significant red flag, not a minor technicality. Verbal answers are easily forgotten or denied later. If a vendor states the answer 'depends on the project,' request a range or an explicit working assumption. Outright refusal warrants considering other proposals.

**Are these questions applicable to an existing vendor when renewing a contract?**
Yes, and sometimes it's even more critical. An existing vendor who has accumulated internal knowledge may stop documenting and self-auditing over time. Re-evaluating every 12-18 months can uncover team attrition, documentation gaps, or slow response times before they escalate into dangerous dependency.

**What relative weight should be given to each of the six topics during the decision-making process?**
There's no one-size-fits-all formula. However, for a first-time project with extensive data sources, dedicating about 45% of the score to Team and Data combined is advisable, 35% to Methodology and Architecture, and the remainder to Commercial Terms and Continuity. For existing contract renewals, the weight shifts significantly towards Continuity and Commercial Terms.

**What's better – a low-cost vendor with generic answers or a more expensive vendor with detailed responses?**
Detailed answers are almost always more valuable. A 15-20% price difference is minor compared to the cost of rework due to incorrect assumptions about data or permissions. A low price with an ambiguous scope often signifies the same work, plus an unpleasant surprise down the line.

---

## Salesforce Project Stuck? Your 90-Day Rescue Plan
URL: https://hpi.pro/en/insights/rescue-stalled-salesforce-project
A stalled Salesforce project often looks like a development issue, but it's usually a cocktail of unclear scope, unmade architectural decisions, and eroded trust. This guide outlines a 10-day diagnostic and a 90-day rescue plan to get your project back on track.

## The Short Answer

Most stalled Salesforce projects aren't stuck due to poor code. They're stuck because no one took the time to ask what's actually changing in users' workflows, who is accountable for each decision, and what happens when something doesn't go as planned. The result: sprint after sprint adding features, without the overall picture improving.

Rescuing a stalled Salesforce project first means stopping the bleeding, and only then deciding what to do with what's already been built. This order is critical: many organizations jump straight to the fixing phase without first diagnosing why the previous process failed, repeating the same mistake a second time. Those looking to understand how to prioritize accumulated debt can delve into [Salesforce Technical Debt Prioritization](/en/insights/salesforce-technical-debt-prioritization).

## Signs of Being Stuck: How to Identify When a Project is Off Track

There's a difference between a slow-moving project and one that's completely stuck. The following signs appear in almost every rescue we've performed:

- **Status discussions turn into explanation sessions**: A weekly status meeting becomes a justification for why something isn't ready yet, without a reliable new deadline.
- **The Backlog grows faster than the closure rate**: New items are added every week, but the number of closed items remains constant or decreases.
- **No version has been tested with a real user in the last month**: Only an internal demo by the technical team, without contact with those who will actually use the system.
- **Frequent requirement changes without documentation**: Every conversation generates "one more small change" that isn't entered into a structured Scope Document.
- **Visible lack of trust**: Users are already building parallel Excel sheets "just in case," a sign they've stopped believing the system will work on time.

When four out of these five signs exist simultaneously, it's a stuck project, not a slow one, and this difference changes the entire treatment strategy.

## 10-Day Diagnosis: What to Check and in What Order

A good diagnosis doesn't require two months. Ten working days, with proper allocation, are enough to get a reliable enough picture for decision-making. Recommended breakdown:

**Days 1-2: Interviews and Initial Mapping.** Short conversations with the Sponsor, process owner, two or three end-users, and the development team lead. The goal is to collect different versions of "what went wrong," not to reach a conclusion yet.

**Days 3-5: Direct Technical Review.** Dive into the Org itself: data model, existing automation, permissions, error logs, and slow queries. Here, check if the problem is architectural or operational.

**Days 6-7: Compare What Was Promised with What Was Built.** Review original documents (SOW, User Stories, Design Docs if available) against the actual state in the Sandbox or Production environment.

**Days 8-10: Formulate Findings and Initial Recommendation.** A short document classifying each identified problem as Scope, Architecture, or Trust, and presenting a first recommendation: Reset, Refactor, or Continue at a revised pace.

## Three Layers of the Problem: Scope, Architecture, and Trust

The most common mistake is treating every project stall as a single problem. In practice, it’s almost always a combination of three different layers, each requiring a different approach.

**Scope problems** manifest when no one truly knows what's included in the first release. This happens when the original definition was too general ("manage the entire sales process in Salesforce") and wasn't broken down into concrete scenarios. The solution isn't another planning meeting but rather writing a sharp Must/Should/Later list, with an Owner for each item.

**Architecture problems** are evident in technical choices that don't scale: a data model that doesn't support the volume of records, automation that runs in the wrong order, or integrations that silently fail. This requires in-depth technical review, and sometimes involves a [Salesforce System Upgrade](/en/insights/salesforce-system-upgrade-signs) as a parallel foundation for the fix.

**Trust problems** are often a result of the first two but take on a life of their own: users stop reporting issues because "they won't fix it anyway," and management stops funding changes because "we already tried." Trust problems aren't solved with declarations, only with small, consistent proofs.

### Diagnosis Table: Symptom, Root Cause, and First Action

| Symptom Observed | Likely Root Cause | Recommended First Action |
| --- | --- | --- |
| Every conversation generates a new requirement | Scope never closed, no definition of Out of Scope | Write a Scope document with an explicit "What is NOT included in this release" section and get sign-off |
| Reports show conflicting numbers | Multiple sources of truth for data, without a Single Source of Truth | Identify the official source field/object and eliminate duplicate reporting |
| The system "freezes" under moderate load | Inefficient automation or update loops | Profile Flow and Apex under simulated load, before any specific fix |
| Users return to Excel | No trust that the system will reflect the actual situation | Quickly fix one major daily pain point, and publicly communicate the fix |
| Technical team doesn't explain its choices | Communication gaps between Business and IT, not necessarily a technical problem | A brief clarification meeting where every technical decision is presented in business terms |
| Every release misses its deadline | Scope expands during work without control | Implement a Change Freeze until the current wave is completed |

## Reset vs. Refactor: How to Decide

This is the central and most expensive decision, so it needs criteria, not gut feelings. Three tests help:

1. **The extent of technical debt versus what's already working.** If 70% of the functionality works reasonably well and only specific parts fail, that's a Refactor. If the problem lies in the fundamental data model, a partial Reset is almost always better.
2. **Cost of explanation versus cost of rebuilding.** If it takes a new team more than a week to understand why something was built a certain way, the future maintenance cost will likely exceed the cost of a clean build.
3. **User trust level.** When trust is very low, a focused and transparent Reset (with an announcement: "we're starting a new, improved version") sometimes achieves more cooperation than a quiet fix users don't notice.

In practice, most successful rescues are hybrid: a Reset for the problematic core component (e.g., the Opportunity model or approval process), alongside a Refactor for the rest of the system. A structured comparison of approaches can be found in [Rebuilding Salesforce](/en/insights/salesforce-rebuild-vs-refactor), which details the criteria for each scenario.

## 90-Day Rescue Plan

| Phase | Days | Primary Goal | Measurable Output |
| --- | --- | --- | --- |
| Stabilization | 1-10 | Damage control, Change Freeze in sensitive areas | Full diagnosis and risk list |
| Decision | 11-20 | Reset vs. Refactor, final scope for first wave | Signed decision document with Owner |
| First Wave | 21-50 | Fix the users' most painful problem | Working and tested end-to-end scenario |
| Expansion | 51-75 | Add capabilities according to agreed priority | Two to three additional processes in use |
| Stabilization & Closeout | 76-90 | Measure against Baseline, Handover Governance | Dashboard, documentation, and maintenance plan |

It's crucial to plan the "First Wave" phase around a single process that users will feel within weeks, not around the most technically interesting component. Projects that fail for a second time often do so by repeating the same mistake: starting with an impressive capability instead of the real pain point. This phase is also directly related to actual performance, and those experiencing response time issues are invited to read [Salesforce Performance Optimization](/en/insights/salesforce-performance-optimization).

## Restoring User Trust

Trust isn't rebuilt by a presentation; it's rebuilt by a consistent pattern of small, kept promises. Here are some principles that have worked in practice:

- **Declare small victories explicitly.** When you've fixed a recurring bug, send a short message explaining exactly what was fixed and who requested it. Such transparency builds more trust than a generic list of achievements.
- **Invite users for early testing, not just UAT at the end.** Someone who sees an intermediate version and feels their feedback was incorporated becomes a project ambassador to the rest of the team.
- **Don't promise a date you're not sure about.** A date delayed for the third time harms trust more than a realistic but less optimistic timeline.
- **Document failures publicly too.** When something didn't work, a brief explanation of what happened and what's changing builds more credibility than silent ignorance.

The trust-building process usually takes longer than the technical fix itself, so it's worth planning it as a parallel track to the 90-day plan, not as an automatic outcome. Organizations seeking structured guidance for this process, including close support for the team and management, can use the [Salesforce Health Check service](/en/salesforce-health-check) as a complete framework.

## Example Organizational Scenario

A financial services company ran a Salesforce project for nine months without going live. Upon review, it was discovered that the Scope had tripled from the original plan, the technical team had built three different versions of the same approval process without documenting why, and key users had already switched to managing their monthly reports in a separate spreadsheet.

The ten-day diagnostic plan revealed that the primary problem wasn't technical: the technical team received conflicting requirements from two different managers who hadn't coordinated. The decision was a partial Refactor, not a full Reset, because most of the code was sound. The first phase focused solely on the approval process, which was the main source of frustration, and within five weeks, a stable version was launched that both managers jointly approved. Only then did they proceed to expand the rest of the processes.

The main lesson: the stall didn't stem from a one-time technical failure, but from the lack of a single entity holding the entire decision map. Such a role, even if temporary, is often the difference between a project that succeeds the second time and one that gets stuck again.

## Checklist Before Deciding on a Rescue Operation

- ☐ A 10-day diagnosis was performed, including interviews, Org review, and comparison with original documents
- ☐ Problems were clearly categorized into Scope, Architecture, or Trust
- ☐ A documented Reset/Refactor decision with justifications was made
- ☐ One process was chosen for the first wave based on real user pain
- ☐ A Change Freeze was implemented for the diagnosis and decision period
- ☐ Baseline metrics were established before starting the fix
- ☐ A continuous communication plan for users and management is in place
- ☐ A single Owner holding the entire decision map has been appointed
- ☐ The 90-day plan includes measurable milestones, not just an end date
- ☐ A process for Governance handover and maintenance at the end of the rescue has been defined

## Professional Resources

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
- HPI Pro – Support & Guidance — https://hpi.pro/support

### Questions and answers
**What's the difference between a 'slow' project and a truly 'stalled' project?**
A 'slow' project still makes decisions and measurable progress, albeit at a reduced pace. A 'stalled' project is one where two to three weeks pass with no new decisions, no version tested by an actual user, and no change in the backlog status. If there's no clear answer to 'what happened this week?' it's likely stalled.

**Should a third-party consultant or an internal team member lead the diagnostic process?**
A third party should ideally lead the diagnostic phase because they aren't responsible for past decisions and can ask uncomfortable questions without eliciting defensiveness. The internal team must be fully involved in interviews and data review; otherwise, conclusions will be perceived as external criticism, not a foundation for joint action.

**Can a project be rescued without replacing the vendor or integrator?**
Yes, and sometimes this is the correct path, especially when the issue is scope and communication, not technical quality. Evaluate this against three questions: Is the current team making clear decisions? Is there transparency in code and documentation? Is there a genuine willingness to pause and correct? If the answer to all three is negative, replacement becomes relevant.

**How long does it take for users to experience the first noticeable improvement?**
In projects with a proper diagnosis, the first noticeable improvement typically appears within 3-4 weeks of starting the 90-day plan, usually through fixing a recurring bug or shortening a daily process. Deeper structural improvements, like data model corrections, take 6 to 12 weeks, depending on the extent of technical debt.

**What happens if the original project sponsor no longer believes in the project?**
This is the strongest indicator of the need for a rescue, not a reason to give up. The first step is to build a small, measurable proof point for that sponsor within two weeks – for example, fixing a bug that personally annoys them daily. Trust is rebuilt through small, repeated demonstrations, not through a detailed plan presentation.

---

## Defining a Salesforce MVP: Build for Tomorrow, Not for Today
URL: https://hpi.pro/en/insights/salesforce-mvp-scope
The true distinction between an MVP and a temporary workaround isn't feature count, but rather the permanence of foundational decisions. A well-designed first wave thoroughly locks down data models and permissions, while strategically limiting business breadth. This article introduces a sharp test for MVP boundaries and a decision matrix outlining what must be decided now versus what can be deferred.

## The Test That Separates an MVP from a Temporary System

Two projects can launch with the same number of screens. One will serve as a foundation for growth, while the other will become technical debt that needs to be dismantled. The difference isn't in scope, but in the type of compromise made.

The practical rule: **For the first phase, reduce business breadth, not architectural depth.** It's acceptable to narrow down the number of processes, units, and customer types being onboarded. However, you must never compromise on the core data model, the authorization model, or the definition of the single source of truth—these should be built correctly once, even if they initially serve only fifty users.

Teams that reduce depth instead of breadth will end up with a system that works for a quarter and then needs to be rebuilt. The broader context of project stages is available in the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## Three Easily Confused Definitions

| Term | What it actually is | When it's suitable | Primary risk |
| --- | --- | --- | --- |
| Proof of Concept (PoC) | Technical feasibility demonstration for a single component | When there's genuine doubt about whether something is possible | Tends to be promoted to production |
| Pilot | Full deployment to a limited group | When the solution is known, and the question is adoption | Group isn't representative enough |
| MVP | First production version that generates real value | When you want to learn from actual use | Becomes permanent without a deliberate decision |

The choice among these three isn't semantic. A PoC can be discarded, but an MVP cannot—which is why an MVP must be built to production standards.

## Decisions You Cannot Postpone

There's a set of decisions whose cost of change increases by an order of magnitude once data is in production. These decisions must be made in the first phase, even if they initially serve only a small part of the overall picture:

- **The object that holds the business process** and its relationship to core entities.
- **The unique key that identifies a customer** across external systems.
- **The default visibility** for every central object.
- **The record ownership structure**—who is the Owner and what happens when an employee leaves.
- **The definition of the single source of truth** for every entity synchronized with another system.

In contrast, decisions that can and should be postponed include: designing advanced reports, convenience automations, integrating secondary channels, localization of units not in the first phase, and integrations not required for real-time decision-making.

## How to Choose the First Phase Process

Don't choose the simplest process, nor the most painful. Choose the process that meets all three conditions: it has a single, available process owner; it produces a result visible to management; and it represents the central data model. A process that meets two out of the three is still acceptable; a process that meets only one will result in a first phase that teaches nothing.

Another consideration is volume: a process that occurs ten times a month won't generate enough usage to learn from within a quarter.

## Exit Criteria – What Signifies a Successful Phase

An MVP without exit criteria becomes a permanent fixture. The criteria must be measurable, concise, and predefined. Example structure:

- A percentage of processes of the chosen type are actually performed within the system, not outside it.
- No blocking defect remains open for more than a defined number of days.
- The data generated during the period meets the predefined quality threshold.
- The process owner confirms in writing that the process runs without a permanent workaround.

Note that none of these is "the system went live." That date is the starting point for measurement, not its end.

## Cost of Delay – The Tool That Resolves Scope Debates

When debating whether a capability belongs in the first phase, the useful question isn't how much it costs to build now, but how much it costs to build later. The following table serves as a working tool in a scope meeting:

| Capability Type | Cost to build in Phase 1 | Cost to build in Phase 2 | Conclusion |
| --- | --- | --- | --- |
| Change to core object structure | Low | Very High – includes migration | Included in Phase 1 |
| New authorization model | Medium | High – exposure has already occurred | Included in Phase 1 |
| Management report | Low | Low | Postponed |
| Alert automation | Low | Low | Postponed |
| Integration required for real-time decision | High | High + entrenched workaround | Included if the process depends on it |
| Integration for reporting only | Medium | Medium | Postponed |

## Illustrative Example: International Logistics Company

This scenario is hypothetical and illustrative. A shipping company operating in three countries wanted to launch an MVP within eleven weeks. The initial proposal was to include all three countries, but only the quote stage, without the order stage.

The team reversed the cut: one country, but the full process from quote to confirmed order, including the integration that pulls rates. The reason was simple—cutting the process in the middle would require users to continue in the old system for the order stage, meaning double data entry. Instead of learning if the system helped, the company would learn that the system was burdensome.

The total scope in weeks remained similar. What changed was that after the first phase, the company had a complete, working process, not half a process across three countries.

## Signs an MVP Has Become a Temporary System

- A permanent manual process exists, intended to "bridge until the next phase," and has been in place for over two months.
- A field was agreed upon to serve two different purposes because there wasn't time to split it.
- A group of users works simultaneously in two systems.
- There's no decision date for the next phase, only a waiting list.

These patterns, along with other failures, are extensively discussed in the [CRM Implementation Mistakes Guide](/en/insights/crm-implementation-mistakes).

## Integration with the Overall Timeline

Defining an MVP directly impacts project duration, and sometimes in the opposite direction expected: too narrow a first phase lengthens the overall project, because each phase carries fixed costs for testing, training, and go-live. How to translate this into a realistic detailed plan is covered in the [Salesforce Project Timeline Guide](/en/insights/salesforce-project-timeline), and in the case of replacing an existing system, also in the [Replacing CRM with Salesforce Guide](/en/insights/replace-crm-with-salesforce).

## Next Step

In one sentence, describe the first phase's process, its process owner, and the criteria that will indicate its success in three months. If any of these three sentences cannot be written right now—that's your starting point, not the feature list.

### Questions and answers
**What's a reasonable scope for a Salesforce MVP?**
There's no fixed number, but a practical test exists: The first wave should encompass a single, complete end-to-end business process for one user group, leveraging only the data truly essential for that process. If you need to truncate the process halfway to meet scope, that signals you've chosen too large a process, not too small an MVP.

**Can core system integrations be deferred to a second wave?**
Potentially, provided the first-wave process doesn't critically depend on it for decision-making. If your sales team needs to simultaneously open the ERP to check inventory or credit limits, deferring the integration isn't saving work; it's creating a workaround that will be difficult to undo later.

**Who decides what stays out of the MVP?**
The decision rests with the business sponsor, guided by recommendations from the process owner and architect – not a committee. The reason is practical: Removing a capability from the first wave is a political concession, and only someone with budgetary authority can uphold that decision without the feature creeping back in through change requests.

**How do you prevent an MVP from becoming permanent?**
Establish measurable exit criteria and a decision date for the next wave upfront, rather than just a continuation list. Furthermore, do not allow the first wave to circumvent architectural decisions. A system that stays permanent on a robust data model is a reasonable outcome; a system that remains permanent on a temporary solution is technical debt.

**Is an MVP approach suitable for replacing an existing CRM?**
Yes, but the boundaries are defined differently. When replacing an existing system, there's pressure to replicate everything the old system did. Therefore, the first wave is often defined by a user group or business unit, rather than a subset of capabilities. Running two systems concurrently for the same group creates duplicate work and compromises data integrity.

---

## Your Salesforce Project Team: Roles, Responsibilities, and Vendor Partnership Model
URL: https://hpi.pro/en/insights/salesforce-project-team-roles
The two roles most critical to a successful, on-time Salesforce project are almost always client-side, not vendor-side. This guide defines nine essential roles, clarifies their impact, identifies those you can't outsource, and introduces a RACI matrix designed to eliminate decision bottlenecks.

## Roles That Dictate Project Pace

Even with an excellent architect, an experienced development team, and a well-organized project manager, a Salesforce project can fall behind schedule. The common reason isn't the pace of building but the pace of decision-making. Development waits for a decision, the decision waits for a meeting, and the meeting waits for a calendar slot.

Therefore, the most effective division of roles isn't about who does what, but rather **who decides what and with what response time**. A review of the stages where each role is required can be found in the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## Nine Roles and Each Mandate

**Executive Sponsor** — Resolves inter-departmental conflicts, approves scope deviations, and protects project priority against competing pressures. If they lack budget authority, they are a representative, not a Sponsor.

**Process Owner** — Defines how work will actually be performed after the change, and confirms that the built process aligns with reality. One for each core process, not a committee.

**Product Owner / CRM Manager** — Manages backlog priorities, resolves conflicting requests, and maintains the connection between requirements and value.

**Project Manager** — Schedule, dependencies, risks, vendor coordination, and reporting.

**Solution Architect** — Makes decisions on the data model, permissions, system boundaries, and implementation approach; responsible for documenting considered alternatives.

**Salesforce Admin** — Configuration, environments, user management, and ongoing maintenance post-launch.

**Developer** — Custom logic, integrations, automated testing.

**Data Owner** — Determines the source of truth, what constitutes a valid record, and who approves data loads.

**Adoption & Training Leader** — Communication, role-based training, change resistance management, and usage measurement.

In a small project, one person might hold two roles, but there are two pairs that should not be combined: Architect and Project Manager (conflict between thoroughness and speed), and Process Owner and Test Lead (testing one's own work).

## Who Must Be Internal

| Role | Can be External | Explanation |
| --- | --- | --- |
| Executive Sponsor | No | Requires organizational authority |
| Process Owner | No | Requires ownership of actual work |
| Data Owner | No | Requires regulatory and business accountability |
| Product Owner | Partially | Guidance is possible, but not replacement |
| Project Manager | Yes | Common and acceptable |
| Solution Architect | Yes | Preferably with internal knowledge guidance |
| Admin | Yes, temporarily | Better to transition to internal before Go Live |
| Developer | Yes | Standard |
| Adoption Leader | Partially | Internal messaging must come from the organization |

## RACI Matrix for Key Decision Points

| Decision | Accountable | Consulted | Required Response Time |
| --- | --- | --- | --- |
| Data Model Structure | Architect | Process Owner, Data Owner | Up to one week |
| Scope Change | Sponsor | Product Owner, Project Manager | Up to one week |
| Backlog Priorities | Product Owner | Process Owners | Up to two days |
| Required Field Definition | Process Owner | Admin | Up to two days |
| Data Load Approval | Data Owner | Architect | Up to three days |
| Production Release Approval | Sponsor | Project Manager, Process Owner | Per defined gate |
| Critical Issue Resolution | Project Manager | Architect, Admin | Same day |

The response time column is the interesting part of the table. A RACI without an SLA for decisions is a nice description that doesn't change the pace.

## Realistic Availability — A Common Planning Error

| Role | Discovery | Build | Testing | Go Live & Weeks After |
| --- | --- | --- | --- | --- |
| Sponsor | Low, consistent | Low | Medium | Medium |
| Process Owner | High | Medium | Very High | High |
| Product Owner | High | High | High | Medium |
| Admin | Medium | High | High | Very High |
| Data Owner | Medium | Low | High | Medium |
| Adoption Leader | Low | Medium | Medium | Very High |

A common planning error is assuming the Process Owner's workload decreases after discovery. In reality, it rises again during the testing phase, precisely when the employee returns to their routine work.

## Illustrative Example: Academic College

This scenario is hypothetical and for illustrative purposes. A college implemented a system for managing applicants. The team was properly defined on paper, but the "Process Owner" was the head of the admissions department who could only dedicate two hours per week to the project. Every question about applicant status awaited until Tuesday morning.

After two months, it was measured that the cumulative delay waiting for decisions exceeded the delay from all other reasons combined. The solution wasn't to hire more developers. The college appointed a deputy who received an explicit mandate to make daily decisions up to a defined impact level, leaving only policy-changing decisions to the department head. Development pace increased without changing the vendor team's size.

## Working Model with the Vendor

Three mechanisms are sufficient for most projects:

- **Shared Decision Log** — Every decision with date, accountable person, rationale, and rejected alternatives. This is also the only documentation that remains useful two years later.
- **Single Point of Contact on Both Sides** — Multiple direct inquiries from various participants to developers are a sure way to lose track.
- **Regular Demo Cycle** — The Process Owner sees a working product, not a presentation. A gap between expectation and reality is discovered within two weeks instead of two months.

In large organizations, an additional layer of governance between business units is required, as described in the [Enterprise Salesforce Implementation Guide](/en/insights/enterprise-salesforce-implementation).

## Intersections with Other Stages

Team composition is directly derived from two things: the deliverables required in the discovery phase, detailed in the [CRM Discovery Guide](/en/insights/crm-discovery-guide), and the scope of the first wave, determined by the rules in the [Salesforce MVP Scope Guide](/en/insights/salesforce-mvp-scope). A narrow first wave requires fewer concurrent Process Owners, which is an independent reason to limit breadth.

## Quick Check Before Starting a Project

Answer four questions using first and last names, not department names: Who decides when Sales and Operations disagree; Who confirms that the built process aligns with reality; Who determines which data is reliable; and Who will maintain the system in a year. A missing answer to any of these is the biggest project risk, and it's also the only one that isn't solved with money.

### Questions and answers
**How much time should a Process Owner dedicate to a Salesforce project?**
During the discovery and design phases, typically between a third and half of their time. This can increase during testing and go-live. The common misconception that a weekly meeting suffices is the leading cause of delays: small daily decisions, too minor for a dedicated meeting, can block development when there's no one to make an immediate call.

**Which roles cannot be outsourced to a vendor?**
Three key roles: the Sponsor, authorized to make cross-departmental decisions; the Process Owner, who defines how work will flow; and the Data Owner, who determines what data is considered reliable. A vendor can provide architecture, development, project management, and even change management, but they cannot decide what’s best for your organization.

**Do we need an in-house Salesforce Admin during the project?**
Ideally, yes, and not just close to completion. An Admin involved from the discovery phase understands the rationale behind decisions, not just the outcome, enabling them to effectively maintain and evolve the system. An Admin handed the system at go-live must learn architecture from configuration, which is slower and error-prone.

**What's the difference between a Product Owner and a Project Manager in a Salesforce context?**
The Project Manager is responsible for schedule, dependencies, risks, and budget. The Product Owner is accountable for content priority: what gets built first and what's deferred. When these roles merge into one person, typically one responsibility is neglected – usually, priority management is sacrificed for meeting deadlines.

**How do you effectively collaborate with a remote external vendor team?**
Implement three mechanisms: a single point of contact on both sides; decisions recorded in a shared decision log, not just emails; and regular, short demo sessions where the Process Owner reviews working deliverables. Language and time zone differences are manageable; what's unacceptable are verbal decisions that no one documented.

---

## Salesforce UAT: Beyond the Screens - Validating Your Business Processes
URL: https://hpi.pro/en/insights/salesforce-uat-guide
A Salesforce User Acceptance Testing (UAT) that merely tours screens won't uncover the critical issues that can derail your go-live. Effective UAT demands complete scenario-based testing, realistic data, and direct user involvement. This guide provides a robust methodology for test case creation, a practical bug severity model, and clear go/no-go criteria.

## Why UAT Fails Even When it Appears Successful

In many UAT cycles, all test scripts are marked as passing, only for dozens of incidents to emerge two weeks after go-live. This isn't a paradox. It's a direct outcome of testing designed around screens.

Screen-based testing asks, "Can a record be created?" Process-based testing asks, "Can an agent receive an inquiry, identify the customer exists under a different name, check their eligibility in the core system, open a case, escalate it to another party, and close it—when the customer exists twice in the system?" The second scenario uncovers what the first misses.

This guide presents a UAT structure that addresses the second question. Its connection to other project phases is detailed in the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## What Must Be Ready Before Starting

- **A stable environment** that doesn't receive deployments mid-cycle, except for approved blocker fixes.
- **Test data** of similar scope and complexity to production.
- **Users with actual permissions**—not Admin for everyone. Half of all permission issues are only discovered when the tester has the correct profile.
- **Defined acceptance criteria** for each core process.
- **A single reporting mechanism** for issues, with minimal mandatory fields.

The item most often skipped is the third, and it's the one that generates the most embarrassing incidents on go-live day.

## How to Build a Test Script That Finds Problems

A good test script starts with a persona and an initial state, not a click. A working structure:

1. **Who** — precise role and permission.
2. **Initial State** — what information exists in the system before the script begins.
3. **What Happens** — the business event that triggers the process.
4. **What the Tester Does** — at a business action level, not a click level.
5. **Expected Outcome** — including what happened in other systems.
6. **What Should Not Happen** — the record is not exposed to unauthorized users, the alert is not sent twice.

The sixth point distinguishes between a checklist and professional testing.

## Six Scenario Families That Must Be Included

| Family | Scenario Example | What it Uncovers |
| --- | --- | --- |
| Happy Path | Complete end-to-end process | Is the process even feasible |
| Business Exception | Cancellation, refund, return to previous stage | Logic built only in one direction |
| Problematic Data | Duplicate customer, name in Hebrew and English, blank field | Insufficient mapping and cleansing |
| Permissions | User attempts to access a record from another unit | Gaps in the exposure model |
| Integration Failure | Target system is unavailable | Error handling, loops, duplication |
| Volume | Batch operation on a large number of records | Performance and automation limitations |

The absence of an entire family from this list is a sign that the testing will provide false confidence.

## Severity Classification — The Key to Managing the Cycle

Without an agreed-upon classification, every defect seems urgent, and the decision to go live turns into an argument. A four-level model is sufficient:

| Level | Definition | Impact on Go-Live |
| --- | --- | --- |
| Blocker | Core process cannot be completed, no workaround | Blocks go-live |
| Severe | Process is possible with a heavy workaround or incorrect data is saved | Blocks go-live unless explicitly approved |
| Medium | Significant inconvenience, reasonable workaround | Does not block go-live, enters remediation plan |
| Low | Wording, field order, enhancement | Collected for the next release |

The important rule: the process owner, along with the technical team, determines the classification, not the person who reported the issue.

## Go-Live Criteria

These are articulated before the start of the cycle, not at its end:

- Zero open blocker defects.
- All severe defects either closed or approved in writing with a workaround and fix timeline.
- All core processes run in a second cycle without new failures.
- Process owners have provided written approval.
- A tested rollback plan exists, not just a written one.

## Illustrative Example: Pension Fund

This scenario is hypothetical and illustrative. A pension fund tested its member inquiry handling process. The first UAT cycle passed almost completely. The team noticed that all testers used a single, extended profile because the assignment of precise profiles was delayed.

In the second cycle, with the actual profiles, eleven defects were found: agents couldn't see records of members who had transferred between schemes, an approval button for an exception appeared for unauthorized users, and a workload report returned partial results for team leads. None of these defects were related to the functionality tested in the first cycle—all were in the exposure model.

The practical conclusion adopted there: do not start a UAT cycle before all participants are on the profile they will use in production.

## Management Mistakes That Increase Cycle Costs

- Deploying versions mid-cycle, which invalidates already performed tests.
- Testers reporting via WhatsApp and email concurrently with the tracking system.
- Scripts written at a click level, turning every UI change into a documentation update.
- Shortening the second cycle due to schedule pressure—this is the cycle that uncovers regressions.

These patterns appear alongside other failures in the [Common CRM Implementation Mistakes Guide](/en/insights/crm-implementation-mistakes), and responsibility for each is defined in the [Salesforce Project Team Roles Guide](/en/insights/salesforce-project-team-roles).

## When Replacing an Existing System

In a replacement project, UAT gains a second role: comparison. The same ten scenarios are executed in both systems, and results are compared field by field. This is the most effective tool to uncover mapping discrepancies before they become trust gaps. The sequence of operations in such a transition is detailed in the [Salesforce CRM Replacement Guide](/en/insights/replace-crm-with-salesforce).

## What Remains After the Cycle

UAT scripts are not a one-time document. They form the basis for regression tests in every future release, and they are the best source for training materials—because they are written in process language, not system language. Storing them in a reproducible format is the cheapest investment one can make for the coming year.

### Questions and answers
**How much time should we allocate for Salesforce UAT?**
A practical timeframe for a medium-sized UAT cycle is two to four weeks. However, the crucial variable isn't just the number of test cases, but the number of remediation cycles needed. Plan for at least two rounds: the first for discovery, and the second to confirm fixes without introducing new regressions. A one-week UAT almost inevitably leads to critical issues surfacing post-go-live.

**Should UAT be performed with live production data?**
UAT should use data that closely resembles live production data in scope and complexity, while respecting privacy limitations. Testing with only ten clean records won't expose duplicates, problematic naming conventions, deeply nested account hierarchies, or missing historical data – precisely the scenarios that cause significant disruption during the first week in production.

**Who should write the UAT test scripts?**
Business process owners should lead test script creation, guided by team members familiar with the system. When developers write test scripts, they often reflect what was built, not necessarily what the business truly needs. The technical team's role is to add edge cases, not define the core business processes being tested.

**What's the difference between UAT and integration testing?**
Integration testing verifies that systems communicate correctly: data formats, field mapping, error handling, and performance. UAT confirms that the end-user can complete their job efficiently and that the business outcome is correct. You can pass all integration tests and still fail UAT if the data flows but the overall process is unexecutable or inefficient for the user.

**Is it ever acceptable to go-live with open bugs?**
Yes, but only if they are properly triaged, documented, and approved. A bug without a reasonable workaround is likely a blocker. However, a bug with a documented workaround and an agreed-upon fix timeline can be carried forward. What's unacceptable is going live with an untriaged list of defects, effectively leaving the go-live decision to end-users during the first week of production.

---

## Salesforce Project Pricing: Fixed Price, Time & Materials, or Retainer?
URL: https://hpi.pro/en/insights/salesforce-project-pricing-models
Choosing a pricing model fundamentally shifts who bears the risk of uncertainty. Fixed Price isn't inherently cheaper, and T&M isn't inherently riskier. Each aligns with a different level of scope definition maturity. Here’s a matching guide, risk mitigation strategies for each model, and hybrid approaches that deliver.

## Pricing Isn't About Cost, It's About Risk

When an organization weighs Fixed Price versus Time & Materials, they typically ask which model is cheaper. That's the wrong question. Both models account for the same work; the difference is **who absorbs the deviation when reality strays from assumptions.**

With Fixed Price, the vendor absorbs the risk—so they build in a risk margin from the outset and protect themselves by precisely defining what's included. With T&M, the organization absorbs the risk—so they need control mechanisms. With Retainer, both sides gain stability in exchange for reduced flexibility.

The simple rule: **the more mature the Scope definition, the more advantageous a Fixed Price model.** The more genuine unknowns there are, the better a capped T&M model.

## Quick Comparison of the Three Models

| Aspect | Fixed Price | Time & Materials | Retainer |
| --- | --- | --- | --- |
| Who Bears Scope Risk | Vendor | Organization | Shared within agreed scope |
| Success Conditions | Well-defined Scope | Transparency and close management | Stable, predictable demand |
| Flexibility for Change | Low, via change requests | High | Moderate |
| Administrative Burden on Org | Medium, focused on definition | High, ongoing | Low |
| Typical Pitfall | Scope creep battles | Hours creep | Unused or absorbed hours |
| Good Fit For | Defined implementation waves | Integration, migration, discovery | Maintenance and continuous improvement |

## Fixed Price — When to Use and What to Watch Out For

Suitable when there's a detailed specification with clear acceptance criteria, known and documented integrations, and verified data quality. In this scenario, the vendor can price with reasonable confidence, and the organization gains genuine budget certainty.

Protective mechanisms to demand:

- Defining "completed" for each deliverable, not just the deliverable's name.
- An explicit list of assumptions underpinning the price.
- A pre-agreed rate for change requests, preventing disputes under pressure.
- A payment schedule linked to acceptance, not arbitrary dates.

Warning sign: A Fixed Price quote given without any questions about data volume, user count, or source systems. Such a price will change; the only question is when.

## Time & Materials — When to Use and How to Control

Suitable when there are unknowns that are not cheap to resolve: an old core system without documentation, historical data of unknown quality, or a business process that's still evolving.

Control mechanisms that make it safe:

- **A cap for each milestone** with an alert when a set percentage of it is reached.
- **Task-level reporting**—task name, hours spent, status.
- **Exit points** at the end of each milestone, with no penalty.
- **An agreed team mix**—how many senior vs. junior hours—to prevent quiet changes.

The last point is often overlooked, yet it impacts cost more than the hourly rate itself.

## Retainer — When it Becomes a Waste

A Retainer works well after go-live, when there's a steady stream of requests. It falters in two opposite scenarios: when demand is low and the organization pays for unused hours, or when significant development work is pushed in, draining support capacity.

Two simple fixes: explicit separation between support and development, and a clause allowing partial rollover of unused hours to the next month, with a cap. Combining both stabilizes the model.

## Hybrid Models That Work in Practice

| Project Phase | Recommended Model | Reasoning |
| --- | --- | --- |
| Consulting & Discovery | Short Fixed Price | Scope is known, deliverable defined |
| Data Migration | Capped T&M | Data quality reveals itself during process |
| Integrations to Legacy Systems | Capped T&M | Dependent on the other system |
| Defined Implementation Wave | Fixed Price | Acceptance criteria exist |
| Stabilization Period | Included in wave price | Prevents disputes over what's a bug vs. change |
| Ongoing Maintenance | Retainer | Consistent demand |

Such a breakdown might seem more complex than a single agreement, but it precisely reduces the arguments that derail projects.

## Illustrative Example: Medical Equipment Importer

This hypothetical scenario is for illustration. An importer requested a Fixed Price quote for a project that included integrating with a fifteen-year-old inventory management system lacking API documentation. The three proposals received had a very wide cost range, and the cheapest included a small print clause: "Assuming a REST API is available."

Before signing, the organization conducted a short, one-week feasibility study. It turned out there was no such interface, and an intermediary layer was required. This study changed the picture: the integration shifted to a capped T&M model, while the rest of the project remained Fixed Price.

What the brief study prevented was not additional cost—that would have come anyway—but a contractual dispute in the middle of the project over who was responsible for an unchecked assumption.

## What Impacts Pricing More Than the Pricing Model

- **Maturity of definition**—incomplete specifications make any model more expensive.
- **Number of source systems** and their documentation level.
- **Quality of existing data**.
- **Availability of process owners** within the organization—decision delays are a direct cost.
- **Number of business units** that need to agree.

Four out of these five are within the organization's control, not the vendor's. This is why investing in preparation reduces project costs more than any negotiation over rates.

## From Model to Agreement

After selecting the model, the wording matters: what constitutes a completed deliverable, who approves it, and what happens when the other party causes delays. The clauses that should be included in the agreement are detailed in the [Salesforce SOW and Contract Guide](/en/insights/salesforce-sow-contract-clauses), and how to draft an RFP to ensure comparable proposals is outlined in the [Salesforce RFP Guide](/en/insights/salesforce-rfp-guide).

The initial selection of the type of service to be priced is detailed in the [Salesforce Services Guide](/en/insights/salesforce-services-guide), and evaluating the vendor itself in the [Salesforce Implementation Partner Selection Guide](/en/insights/choose-salesforce-implementation-company).

## Next Step

Before requesting pricing, rank the three biggest sources of uncertainty in your project. If you can name them, you're ready for a Fixed Price model for part of the work. If you can't, the first thing to procure is a short discovery phase to remove those uncertainties, not a quote for the entire project.

### Questions and answers
**Does Fixed Price truly protect my budget on a Salesforce project?**
It fixes the price of the *defined* scope, not necessarily the entire project. When the definition is partial, the gap is closed through change requests, which are separately priced and often at a higher rate. Fixed Price protects your budget only when the scope document is detailed enough for both parties to agree on what's in and what's out.

**When is Time & Materials (T&M) preferable to a fixed price?**
When there's genuine uncertainty that cannot be resolved before work begins—think integrations with legacy systems lacking documentation, unknown data quality, or evolving business processes. In such scenarios, Fixed Price simply bakes that uncertainty into a risk premium you pay whether it materializes or not.

**What's typically included in a monthly Salesforce retainer?**
Generally, a retainer covers maintenance, support, minor configuration changes, release management, and monitoring. Significant new feature development should be outside the retainer or subject to a defined cap, otherwise, it consumes hours meant for support, creating the impression that your vendor is unavailable.

**How can we prevent inflated hours with a T&M model?**
Through three mechanisms: an agreed-upon ceiling for each milestone with early warning notifications as it's approached, task-level time reporting rather than monthly summaries, and the client's right to pause at the end of any milestone. Together, these provide better control than a fixed price, allowing for course correction mid-project.

**Can different pricing models be combined within the same project?**
Yes, and this is often the most effective approach. A common pattern is Fixed Price for the discovery phase, T&M with a cap for integrations and data migration, Fixed Price for defined implementation sprints, and a Retainer for post-go-live support. This hybrid approach aligns each project component with the model best suited to its level of uncertainty.

---

## Salesforce Flow vs. Apex: Your Definitive Decision Framework for Enterprise Automation
URL: https://hpi.pro/en/insights/salesforce-flow-vs-apex
Choosing between Salesforce Flow and Apex isn't just about team skill sets. It hinges on transaction volume, Governor Limit impact, required transaction control, and logic complexity. This article provides a practical, operational decision-making framework, moving beyond generic capability comparisons.

## The Short Answer

The question "Flow or Apex" receives an incorrect answer when evaluated based on ease of writing or developer availability. The correct answer depends on four technical factors: how many records are processed in a single transaction, whether the logic requires full atomicity, how complex the conditions and branches are, and who will maintain the component in a year. Flow is the right default for most business automations—but there are clear transition points where continuing to use Flow creates an operational risk, not just "less elegant code."

This article focuses on the decision-making process itself: how to identify in advance that the logic justifies Apex, and how to prevent situations where the choice is made by default rather than by deliberate consideration. The issue of cleaning up existing Flows and automation processes that have accumulated as technical debt is discussed in a separate article and is not part of this discussion.

## What Actually Differentiates Them at the Platform Level

Flow is a declarative engine that is translated at runtime into instructions that execute DML and SOQL on behalf of the user, whereas Apex is compiled code that runs under the same Governor Limits but with direct control over the order of operations. The first practical difference is bulkification: an Apex developer explicitly builds a loop that collects all records into a single array and runs a single DML, while in Flow, it's easy to build a loop that performs a DML operation or a query in each iteration separately—a pattern that reaches the 101 allowed queries much faster.

The second difference is transaction control. Apex allows `Savepoint` and `Database.rollback` for partial undo, handling `DmlException` at the single record level via `Database.insert(list, false)`, and complex conditional logic without branch depth limits. In Flow, error handling is defined at the Fault Path level for each element, and this works well for linear scenarios but becomes difficult to track with more than a few parallel fault paths.

## Decision Framework: Four Tests Before Choosing a Tool

### Volume Test

Rule of thumb: If the process runs on a single record as a result of user action (creating a lead, changing opportunity status), Flow is almost always sufficient. If the process runs on tens to thousands of records at once—periodic updates, handling a batch from an integration, scheduled data cleanup—Apex with `Batchable` or `Queueable` is the safe choice, as it provides full control over bulkification and managing Governor Limits against varying volumes.

### Atomicity Test

Ask: If part of the update fails, is it acceptable for the other part to remain saved? If the answer is "no"—for example, an order update and the creation of a billing record that must happen together—Apex with Savepoint is the correct way to ensure this. Flow does not provide full rollback between elements without complex manual construction of compensation logic.

### Branch Complexity Test

A Flow with more than 6-8 nested Decision Elements becomes hard to read and expensive to test, even if each individual branch is simple. When the complexity of the business logic exceeds this, writing the same logic as a documented Apex function with unit tests (`@isTest`) is usually cheaper to maintain, even if the initial writing time is longer.

### Maintenance and Ownership Test

Ask who will maintain the component in a year, not who is building it now. If the Admin team is the one that will need to update business rules regularly—such as changing discount conditions or threshold values—Flow is preferable even if Apex is technically "cleaner," because it is accessible for updates without a deployment cycle. If the changes require knowledge of the data schema and regression testing, Apex is the correct choice even if there is only a small development team to maintain it.

## Decision Table

| Criterion | Choose Flow | Choose Apex |
|---|---|---|
| Record Volume in a Single Transaction | Up to a few dozen | Hundreds to thousands |
| Atomicity Requirement Between Multiple Objects | Not critical | Critical – full Rollback required |
| Number of Decision Branches | Up to ~6-8 | Above this, or recursive logic |
| Rate of Business Rule Changes | Frequent, by Admin | Rare, requires regression testing |
| Need to Call Complex External API | Single simple call (HTTP Callout) | Retry logic, complex Auth, or Batch |
| Requirement for Automated Testing (CI) | Limited | Full, `@isTest` with Coverage |
| Integration with Scheduled Job | Not directly suitable | Native via `Schedulable` |

## Example Scenario: Medical Device Company with Order Approval Process

A medium-sized medical device company with about 40 sales representatives used a single Flow for its order approval process: checking inventory, calculating discounts, creating an approval record, and sending an alert to the manager. Initially, it worked well for a single order. After six months, a new scenario was added—batch order import from a file integrated with the ERP, creating between 200 and 800 orders simultaneously.

The Flow, which was triggered by a Record-Triggered Flow at the "per record" level, performed an inventory check query within each individual execution. With an import of 500 orders, the system exceeded the 100-query limit in a single transaction, and orders failed without a clear error message to the user. The team identified that the problem was not with the Flow itself, but with the mismatch between a process designed for a single record and a high-volume scenario that did not exist at the time of build.

The solution was not to discard the Flow. The team split the logic: Flow remained responsible for the manual process of a single order (low volume test, frequent updates of discount rules by Admin needed), while the batch import process was moved to an Apex Batch Job that performs full bulkification, checks inventory in one centralized query, and runs a single DML for all records. Both mechanisms call the same shared business logic layer (a single Apex Class that the Flow also calls via an Invocable Method), so that the discount rule is not maintained twice.

## Common Risks and Preventive Actions

| Risk | What it Looks Like in Practice | Preventive Action |
|---|---|---|
| Flow on gradually increasing volume | Process worked for six months, then failed silently on Governor Limits | Assess expected volume in advance and plan a transition point to Apex before reaching the limit |
| Duplicate business logic in Flow and Apex | Two places calculate discounts differently | Centralize business calculations in a shared Apex layer that Flow also calls |
| Unexpected Trigger Order | Several Flows and Triggers on the same object conflict | Use one central Trigger Handler in Apex for every critical object |
| Partial error handling in complex Flow | Some records are updated and some are not, without visibility | Move processes requiring Atomicity to Apex with Savepoint |
| Apex without sufficient tests | A small change breaks a critical process in the next deployment | Demand true Coverage, not just a formal percentage, including failure scenarios |

## Pre-Build Decision Checklist

- ☐ Expected volume for a year, not just current state, has been assessed
- ☐ It has been determined if the process requires atomicity between several objects
- ☐ The expected decision branches in the logic have been counted
- ☐ It is known who will maintain the component and how often rules will change
- ☐ It has been checked if similar logic already exists in Apex or another Flow on the same object
- ☐ Trigger Order has been defined if there are multiple automation mechanisms on the object
- ☐ If Apex is chosen—test scenarios, including partial failure, have been defined
- ☐ If Flow is chosen—a Fault Path has been defined for every critical element

## How This Connects to the Broader Architecture

Choosing the right tool for a single automation is just one layer within a broader picture of [CRM Architecture](/en/insights/crm-architecture-guide), where both data models and permissions affect what Flow or Apex can even touch. When automation crosses into an external organization—for example, real-time inventory checks against an ERP—the choice between Flow and Apex also integrates into considerations of [Integration Patterns](/en/insights/salesforce-integration-patterns) and how [Salesforce Connects to ERP](/en/insights/salesforce-erp-integration) in terms of latency and failure handling.

In organizations operating multiple Orgs, it is also necessary to check if the business logic is identical across all of them—a topic discussed in the [Single Org vs. Multi Org Guide](/en/insights/salesforce-single-org-vs-multi-org) and impacting whether it is worthwhile to centralize the logic in a shared Apex package.

## Summary

The choice between Flow and Apex is not a question of team skill or personal preference, but rather a result of four technical tests: volume, atomicity, branch complexity, and frequency of change. Flow is the correct default for most automations dealing with a single record and changing frequently. Apex is required when there's significant volume, when full transaction control is needed, or when logical complexity exceeds the threshold that can still be maintained through a declarative interface. An organization that institutionalizes these tests as part of its workflow—rather than leaving them to ad-hoc developer discretion—will avoid most cases where an automation that initially worked well silently breaks as volume grows.

### Questions and answers
**Can I start with Flow and transition to Apex later without breaking the process?**
Generally, yes, especially if your Flow is built around a clear business event rather than a specific screen. When Flow invokes a process via an Invocable Action or Subflow, you can swap the internal implementation to Apex without altering the trigger, permissions, or interface. Issues arise when Flow and business logic are tightly coupled, making changes a rebuild rather than a refactor.

**Can Flow handle updating thousands of records at once?**
Technically, yes, but practically, it depends on the logical complexity within the loop. A Flow executing SOQL queries or DML statements inside a loop for each record is prone to hitting Governor Limits much faster than a comparable Apex solution. This is because the Flow Engine doesn't always automatically perform bulkification with the same efficiency. For consistent, large-scale updates, Apex with Batch or Queueable is the safer choice.

**What happens when multiple Flows and Triggers operate on the same object?**
Salesforce determines the execution order, which might not always align with your team's intent. This can lead to unpredictable results when multiple mechanisms touch the same record. The best practice is to centralize all automated logic for a core object around a single Apex Trigger Handler, using Flow only for processes that don't conflict with critical core logic.

**When should I write Apex even if Flow is technically sufficient?**
Use Apex when the logic involves a single transaction that must entirely succeed or fail together – for instance, updating two related objects that must never be out of sync. Flow handles errors at the individual element level and doesn't always guarantee full atomicity, whereas Apex allows for controlled Savepoints and Rollbacks.

**Is Apex always more expensive to maintain than Flow?**
Not necessarily. A complex Flow with dozens of decision branches, embedded Subflows, and hidden logic within Formula Fields can be harder to debug than well-documented Apex code with comprehensive unit tests. Maintenance costs depend on the scope of the logic and the quality of documentation, not solely on the tool itself.

---

## Real-Time, Batch, or Event-Driven? Choosing the Right Salesforce Integration Pattern
URL: https://hpi.pro/en/insights/salesforce-integration-patterns
A poor integration pattern choice won't surface during a demo. It reveals itself when your system load spikes, an external system goes down for a minute, or two users update the same customer record simultaneously. This guide provides a decision framework based on just three critical questions: How quickly do you need to know? Who owns the single source of truth? And what happens when something fails?

## Three Questions That Dictate the Pattern — Not the Tool

A common mistake when choosing a Salesforce integration is starting with the tool: MuleSoft, Platform Events, Bulk API, or a simple Webhook. The tool is a result, not a starting point. Three questions determine the correct pattern:

1.  **How quickly does the other side need to know?** A second, a minute, an hour, or a day – this differentiates Real-Time from Batch.
2.  **Who owns the data at any given moment?** If the answer isn't unambiguous, no technical pattern will solve the problem.
3.  **What happens when the other side is unavailable?** "We'll just try again" isn't an answer – defined behavior is needed: Retry, a queue, or explicit failure.

Anyone who answers these three questions before selecting a technology will almost always arrive at the same conclusion an experienced architect would – but without paying for trial and error in production. More on the connection between this decision and the overall architecture can be found in our [CRM Architecture Guide](/en/insights/crm-architecture-guide).

## The Pattern Map: When Each Is Appropriate

| Pattern | Typical Response Time | Typical Use Case | Maintenance Cost | Primary Risk |
| --- | --- | --- | --- | --- |
| Synchronous Request-Reply | Milliseconds to Seconds | Credit check before transaction approval on screen | Medium | Timeout blocks the user |
| Fire-and-Forget | Immediate upon sending, no waiting for results | Sending an event to create a Task in another system | Low-Medium | Silent failure without monitoring |
| Periodic Batch | Hours to a day | Product catalog synchronization once a day from ERP | Low | Time gaps between systems |
| CDC (Change Data Capture) | Seconds to Minutes | Order status update affecting support | Medium-High | Event Bus overload with multiple changes |
| Event-Driven (Platform Events / Pub-Sub) | Seconds | Notification of a business event to multiple consumers simultaneously | High during setup, low during maintenance | Requires Schema and Versioning discipline |

This table is a starting point for discussion, not a final verdict. A single system can, and sometimes must, use several patterns simultaneously based on the data type.

## Why Latency Isn't Enough to Decide

The second common mistake: deciding based solely on Latency and ignoring Consistency. A fast pattern that updates only one side, leaving the other "almost synchronized," creates a more severe problem than a slower but consistent pattern – because users learn not to trust the data, and then bypass the system.

The correct question is a dual one: how quickly is a response required, **and how critical** is a situation where the two sides are momentarily out of sync. A pricing process presented to a customer demands both speed and full consistency – here, a synchronous Request-Reply with a defined Timeout and explicit error handling is necessary. Updating "article views" can comfortably tolerate a delay of minutes – there, Fire-and-Forget or CDC suffice.

## Data Ownership: A Decision Preceding Any Pattern

Before deciding how data flows between systems, it's crucial to determine where it is "authoritative." A field updated in two systems without a defined owner creates a synchronization loop: A sends to B, B updates and broadcasts back to A, A sends again. This isn't an edge case – it's the expected result of bi-directional synchronization without a clear rule.

A practical working rule: for every shared field, assign a single Owner. If there's a genuine business need for editing from both sides (e.g., customer service updates an address in both Salesforce and ERP), add an explicit Conflict Resolution rule – last timestamp wins, or one field dictates while the other is for display only. Managing permissions around these sensitive fields is discussed in the [Salesforce Permission Model Guide](/en/insights/salesforce-permission-model).

## Error Handling: The Test Most Projects Skip

Almost every integration undergoes Happy Path testing. Few undergo systematic testing of these three failure scenarios:

-   **The secondary system is unavailable at the time of sending** – Is the message saved in a queue and resent, or is it lost?
-   **The message arrives twice** (a common problem with automatic Retry and Event Buses) – Does the receiving side create a duplicate record?
-   **Messages arrive out of order** – Does a "canceled" status update arriving before "approved" result in incorrect outcomes?

A system not built as Idempotent (a unique identifier for each message + checking if it has already been processed) will fail precisely in the first two scenarios, and often under load – meaning exactly when the business is most reliant on it. API limitations and handling Throttling in this context are detailed in the [Salesforce API Limits Resilience Guide](/en/insights/salesforce-api-limits-resilience).

## Decision Framework: From Business Question to Pattern

| First Question Asked | If the Answer is "Yes" | If the Answer is "No" |
| --- | --- | --- |
| Is a user on screen waiting for the integration result? | Synchronous Request-Reply with defined Timeout | Move to the next question |
| Is an update of a single change required within minutes? | CDC or Platform Event | Move to the next question |
| Do multiple different consumers need to know about the same event? | Event-Driven with Pub-Sub | Move to the next question |
| Is it convenient to process a large volume within a fixed time window? | Periodic Batch | Consider Fire-and-Forget with a queue |

This is a starting point for discussion in an architecture meeting, not an exhaustive formula – there are always edge cases (e.g., huge volume requiring CDC but also daily Batch Reconciliation as a safety net).

## Illustrative Scenario: A Chain of Twenty Private Clinics

Consider a chain of clinics using Salesforce for patient inquiry management and a separate billing system that cannot be replaced at this stage. The requirement: when a patient completes an appointment, the billing system must be updated immediately, and when a payment is updated (e.g., payment received), Salesforce needs to reflect this so a service representative doesn't request double payment.

The team's initial choice was a bi-directional nightly Batch – simple to set up, but it created up to a 24-hour lag where representatives saw outdated information, leading to complaints. The solution ultimately chosen: one direction (appointment completion from Salesforce to billing) transitioned to Fire-and-Forget with a message queue and automatic Retry, because the user doesn't need to wait. The other direction (payment confirmation from billing to Salesforce) transitioned to CDC, as it was a specific change that needed to arrive within minutes. Nightly Batch remained only as a Reconciliation mechanism – a daily comparison that identifies and flags discrepancies, not as the primary update channel.

The result: update time decreased from hours to minutes, and the Reconciliation mechanism caught two instances of lost messages in the first month – exactly its purpose.

## Risks and Specific Prevention Actions for Integrations

| Risk | How it Manifests in Practice | Prevention Action |
| --- | --- | --- |
| Lack of Idempotency | Duplicate records after Retry or network failure | Unique message ID + existence check before creation |
| Undefined Source of Truth | Synchronization loop or random "winning" update | Defined Owner for each field + Conflict Resolution rule |
| Point-to-Point without Integration Layer | Any schema change in one system breaks another connection | Middleware/API layer with explicit versioned contracts |
| Technical Monitoring Only | Integration is "green" but orders are actually missing | Business Reconciliation metric, not just technical Uptime |
| Ignoring Governor Limits | Integration crashes precisely at peak load | Plan for Bulkification and Backoff proactively, not reactively |

## Integration Pattern Selection Checklist

-   ☐ Required response time defined in numbers, not just the word "fast"
-   ☐ A single Owner defined for each shared field between systems
-   ☐ What happens when the other side is unavailable has been checked and documented
-   ☐ What happens when a message arrives twice has been checked
-   ☐ What happens when messages arrive out of order has been checked
-   ☐ A Reconciliation mechanism exists even when the primary pattern is asynchronous
-   ☐ API limitations and Governor Limits have been checked against expected peak load volume
-   ☐ Business rather than just technical success metrics have been defined

## Metrics for Ongoing Integration Monitoring

After launch, it's advisable to track only three to four metrics: the success rate of messages on the first attempt, actual end-to-end time vs. defined SLA, daily Reconciliation discrepancies between systems, and proximity to API limits. A consistent rise in any of these – not just a one-off anomaly – is a signal to consider transitioning to a different pattern, before the system fails in production. Considerations for identity and access permissions between systems are detailed in the [Salesforce SSO & Identity Architecture Guide](/en/insights/salesforce-sso-identity-architecture).

## Summary

Choosing the right integration pattern doesn't start with "which tool," but with three questions: how quickly is a response needed, who owns the data, and what happens when something fails. Real-Time is suitable when a user is waiting for a result; CDC and Event-Driven are suitable for rapid updates of a single change or distribution to multiple consumers; Batch is suitable for large volumes within a fixed time window. In every pattern, Idempotency, defined data ownership, and a Reconciliation mechanism are not "nice-to-haves" – they are prerequisites for the integration to withstand real load, not just a demo.

## Professional Resources

-   Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
-   Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
-   HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
-   HPI Pro – Integrations & Data — https://hpi.pro/integrations-data

### Questions and answers
**What's the practical difference between Fire-and-Forget and Request-Reply in Salesforce integration?**
In Request-Reply, the caller waits for a response and receives immediate confirmation of success or failure. This is suitable when a user is interacting with a screen and needs an immediate outcome to proceed. With Fire-and-Forget, the sender proceeds immediately, and any response arrives asynchronously. This is ideal for updates that don't block a human-driven process. Choosing incorrectly can force users to wait for systems not designed for waiting, or it can silently obscure critical failures.

**When is CDC (Change Data Capture) preferable to periodic Batch processing for data synchronization?**
CDC is superior when the volume of changes is small relative to the total data volume, and when changes need to be reflected within minutes rather than hours—for example, updating an order status that impacts customer service. Batch processing is better when it's convenient to process large volumes within a fixed time window, when the source doesn't support event streaming, or when the processing itself requires calculations across a complete set of records rather than just individual changes.

**How do you handle message duplication in event-driven integrations?**
Assume every message might arrive more than once and design the receiving end to be Idempotent. Implement a unique identifier for each message, check if it's already been processed before executing the action, and store the result so that re-running doesn't create duplicate records or update twice. Relying on the assumption 'the message will only arrive once' is the first assumption that breaks under load or network failure.

**Who is responsible for the 'source of truth' when the same field is updated in both Salesforce and an external system?**
It's crucial to decide upfront which system owns the field and document this in the integration contract, not just in team discussions. Two-way updates without a defined owner inevitably lead to synchronization loops and timing-dependent outcomes. If true bi-directional editing is required, a clear conflict resolution rule is necessary—for example, 'last update wins' based on a timestamp—rather than assuming this scenario won't occur.

**How can you tell if a chosen integration pattern is still suitable after a tenfold increase in load?**
Monitor three key indicators: processing time (does it still meet defined SLAs?), failure rates (has the failure and retry rate exceeded preset thresholds?), and Salesforce API limits (are Governor Limits or API calls nearing their ceiling?). An increase in any of these metrics signals the need to consider transitioning from Batch to CDC, implementing queuing, or splitting into parallel processes, all before system failures impact production.

---

## Salesforce Permissions Model: Designing Secure Access Without Over-Provisioning
URL: https://hpi.pro/en/insights/salesforce-permission-model
Most organizations build their Salesforce permissions top-down: starting with broad Profiles, then making granular adjustments until no one remembers why a user has certain access. The correct approach is the opposite: a restrictive Profile for baseline access, and Permission Set Groups that build work capabilities based on roles. This article presents a framework for operationalizing this approach.

## The Basic Question: What Governs User Access

When someone asks, "How did a user get access to this field?", the correct answer is almost always a combination: their Profile determines baseline access, assigned Permission Set Groups add role-based capabilities, and sometimes a single, additional Permission Set handles a specific exception. The practical problem is that most organizations build this combination in reverse—starting with a broad Profile that contains almost everything, then "fixing" specific issues with individual permissions that no one remembers to remove.

A healthy permission model is built in the opposite direction: a Profile that is as narrow as possible, primarily defining licensing, default app access, and login characteristics; and all actual work capabilities—which objects, which fields, which actions—are moved to Permission Sets and Permission Set Groups. It's important to clarify: this article focuses solely on Object, Field, and System Permissions. Questions about record visibility between users—OWD, Role Hierarchy, Sharing Rules—are discussed in the [Visibility and Sharing Guide](/en/insights/crm-architecture-guide), as this is a separate decision layer with its own trade-offs.

## The Three Units and Each's Role

| Unit | What it Determines | How Many a User Can Have | When to Choose It |
| --- | --- | --- | --- |
| Profile | Licensing, default App Visibility, Page Layout, Login Hours/IP | Exactly one | Infrastructure differences between user types |
| Permission Set | Object, Field, Apex Class, Tab permissions - additive only | As many as needed | A single capability relevant to some roles |
| Permission Set Group | Bundling several Permission Sets under one name, with Muting capability | As many as needed | A fixed combination of permissions representing a complete job role |

The difference between a Permission Set and a Permission Set Group is not just technical—it's organizational. A single Permission Set is suitable for one focused capability ("Access to Financial Reports"). A Permission Set Group is suitable when you want to assign a complete "work package" to a department or role and maintain it in one place as it changes.

## Decision Framework: Where a New Permission Belongs

When a request arises to add access, the first question isn't "which Profile to add it to" but rather to which unit the permission structurally belongs:

1.  **Is this a permission characteristic of all users with the same license type?** If so, this is a place for a Profile, provided it applies to all license holders and not a sub-group.
2.  **Is this a work capability that a specific role group always needs along with other permissions?** If so, this is a place for a Permission Set Group, even if it needs to be broken down into several separate Permission Sets first to allow flexible combination.
3.  **Is this a specific and temporary permission for a single user or an exception?** If so, an independent Permission Set, manually assigned and reviewed during periodic audits.
4.  **Is the permission meant to revoke something from a specific user within a broad group?** This is where a Muting Permission Set within a Permission Set Group comes in—the only tool in Salesforce that allows reducing a permission without touching the Profile or disassembling the group.

The rule that prevents most drift: Never edit a Profile to solve a single user's problem. If the fix is defined as an exception, it goes through a Permission Set that is documented and has an audit date.

## Checklist for Building a Permission Model from Scratch

- ☐ Actual job roles (not organizational departments) have been mapped, and each role has a clear name.
- ☐ For each role, a list of required capabilities at the object, field, and Apex Class level has been defined.
- ☐ Focused Permission Sets have been built for single capabilities, not generic "permission piles."
- ☐ Each role has been assigned one Permission Set Group that consolidates relevant capabilities.
- ☐ Profiles have been narrowed down to licensing and infrastructure differences only.
- ☐ A process has been defined for exception cases: who approves a specific Permission Set and for how long.
- ☐ An audit cadence (at least quarterly) has been established to compare active permissions against the current role.
- ☐ A single owner has been designated for maintaining the permission model in response to organizational structure changes.

## Organizational Scenario: An Insurance Company with Three Sales Units

Imagine a mid-sized insurance company with about three hundred Salesforce users, divided into three units: direct sales, agent sales, and claims. Before the project, the company had twelve different Profiles, some almost identical copies created to "fix" a single permission for a small group. A typical result: when a new agent joined, no one knew for sure which of the twelve Profiles was suitable for them, and the actual answer was "copy from someone similar."

The architectural team rebuilt the model: only three Profiles, based on license type (full Sales Cloud, Community for external agents, Service Cloud for claims). Above them, seven Permission Set Groups according to actual job roles—sales representative, sales team manager, external agent, agent manager, claims examiner, claims manager, and a bridging role that handles both sales and claims. Each Permission Set Group was composed of focused Permission Sets like "Access to Active Policies" or "Approve Refunds up to a Defined Limit," so they could be recombined when a new role was created without building permissions from scratch.

The measured outcome: the time to onboard a new user dropped from several days (which included manual checking of the appropriate Profile) to a few hours, and the number of support requests such as "I don't have access to field X" decreased by half in the quarter following the transition, because most of these requests stemmed from a Profile that did not include the capability, and it was unclear whom to contact for a fix.

## Common Risks and Preventive Actions

| Risk | How it Appears in Practice | Preventive Action |
| --- | --- | --- |
| Profile becomes an ad-hoc fix tool | Proliferation of almost identical Profiles, each for a small group | Move all specific permissions to a Permission Set and narrow Profiles to licensing only |
| Inconsistent Field-Level Security | The same field is exposed in one place and blocked in a parallel place | Document a central FLS matrix for every sensitive field and review it in each release |
| "Sticky" permissions after a role change | A user who changed roles retains permissions from the previous role | Offboarding-from-role process that removes old Permission Set Group before adding a new one |
| Overly broad System Permissions (View All Data, Modify All) | Granted "to save time" and not removed afterwards | Dedicated approval and expiration date for all broad system permissions |
| Lack of ownership for the permission model | Each team adds permissions without an overall view | Single owner who approves every new Permission Set or Group before deployment |

## Metrics for Model Health Assessment

| Area | What to Measure | Review Cadence |
| --- | --- | --- |
| Unnecessary Duplication | Number of active Profiles compared to the number of actual license types | Quarterly |
| Permission Accuracy | Percentage of users whose permissions match their documented HR role | Quarterly |
| Open Exceptions | Number of specific Permission Sets without a review date | Monthly |
| Broad Permissions | Number of users with View All Data / Modify All Data without documented justification | Monthly |
| Onboarding Time | Average time from new access request to full allocation | Continuous |

For the initial version of tracking, it is advisable to use three out of the five metrics and expand only after a reliable baseline is established. A metric without an owner and a review date tends to disappear from the report after the first month.

## How it Integrates into the Broader Architecture

A good permission model is a prerequisite, not a substitute, for planning record visibility (OWD, Role Hierarchy, Sharing Rules)—these two topics are complementary but resolved separately. An organization that tries to solve a visibility problem by expanding a Profile, or vice versa, usually finds the solution brittle as soon as the organizational structure changes. When the organization moves between multiple Orgs and a single Org, the permission model is one of the things that needs to be remapped—an expansion on this topic appears in the [Single Org vs. Multi Org Guide](/en/insights/salesforce-single-org-vs-multi-org). And when the permission itself depends on complex conditional logic, it's worth considering whether the implementation belongs in Flow or Apex, as detailed in the [Flow vs. Apex Guide](/en/insights/salesforce-flow-vs-apex).

In organizations running event-driven processes between systems, it's important to ensure that the permissions of service users (Integration Users) are built on the same principle—a focused Permission Set and not a broad Profile with "System Administrator" as a convenient default. This topic connects to the broader planning of inter-system communication, described in the [Salesforce Event-Driven Architecture Guide](/en/insights/salesforce-event-driven-architecture).

## Summary

A permission model that stands the test of time is built from the bottom up: focused capabilities in Permission Sets, assembled according to real job roles in Permission Set Groups, and a Profile that maintains a minimal role of only licensing and infrastructure. The clear sign of failure is a proliferation of Profiles created to solve specific problems—each additional Profile of this kind is a debt that accumulates until no one remembers why it exists. When internal capacity is lacking to build or clean up an existing model, [CRM Architecture services](/en/crm-architecture) offer a practical path to a focused start.

### Questions and answers
**What's the practical difference between a Profile and a Permission Set?**
Every user has exactly one Profile, which dictates non-permission related settings like default App Visibility, Page Layout Assignment, Login Hours, and IP Ranges. A Permission Set is an add-on that only grants access and never revokes it. The design takeaway: keep Profiles minimal and build most user differences with Permission Sets.

**When should multiple Permission Sets be combined into a single Permission Set Group?**
When a group of users – for example, 'Senior Service Agent' – consistently requires the same combination of permissions from several separate Permission Sets (e.g., access to cases, refunds, and a knowledge base). Grouping them prevents repetitive manual assignments and reduces errors where users receive only a partial set of required role permissions.

**Can a Permission Set revoke a permission granted by a Profile?**
No. Salesforce permissions are additive only; a Permission Set adds, never restricts. If you need to revoke specific user access without affecting others, the solution is a Muting Permission Set within a Permission Set Group, not editing their Profile.

**How many Profiles should a medium-sized organization have?**
There's no single number, but a useful rule of thumb: the number of Profiles should reflect licensing and infrastructure differences (License Type, default app access), not permission differences between roles. An organization with dozens of Profiles is almost always using them to compensate for a lack of organized Permission Set Groups.

**How do you ensure added permissions don't remain active longer than necessary?**
By assigning a time-limited Permission Set (Permission Set License with an expiration date where relevant, or a quarterly audit process) rather than a permanent permission. Additionally, run periodic reports comparing active permissions against current roles in HR data, flagging discrepancies for review.

---

## Salesforce Single Org vs. Multi-Org: Strategic Considerations for Enterprise Organizations
URL: https://hpi.pro/en/insights/salesforce-single-org-vs-multi-org
Often, the decision to implement a multi-org Salesforce architecture isn't a singular choice, but rather an evolution driven by distinct business units, regulatory requirements, or incompatible data models. This article provides a three-question litmus test to assess your true need, a cost-benefit comparison matrix, and a phased roadmap for organizations already on the path to a multi-org split.

## The Three Questions That Determine If You Need a Multi-Org Setup

The common misconception is to approach the question "One Org or multiple?" as a technical issue of capacity or performance. In most cases, the technical solution exists within a single Org: Record Types, Profiles, Permission Sets, and Sharing Rules are sufficient to separate business units without splitting the environment itself. Salesforce supports tens of thousands of users and millions of records within a single Org — capacity is almost never the real reason for a split.

The question that truly matters is one of organizational autonomy, and it breaks down into three tests:

1.  **Genuine regulatory independence** — Is there a legal or contractual requirement for physical data separation (e.g., a separate legal entity with local regulation prohibiting infrastructure sharing), as opposed to logical separation achievable with the Sharing Model.
2.  **Incompatible pace of change** — Does one business unit require frequent and rapid Release cycles while another demands maximum stability and strict auditing, making any shared Release a constant point of friction between teams?
3.  **Conflicting data model at its core**, not just different — When the same entity (e.g., "Customer" or "Order") has a mandatory field definition, approval flow, or relationship structure that physically contradicts between units, rather than merely differing in display.

If none of these three conditions unequivocally apply, the correct solution is a single Org with logical separation. Splitting "just to be safe" creates ongoing operational overhead — duplicate user management, duplicate licensing, and duplicate integration maintenance — for a problem that could have been solved with configuration.

## Decision Matrix: One Org vs. Multiple Orgs

| Dimension | Single Org with Logical Separation | Multiple Separate Orgs |
| --- | --- | --- |
| Licensing and Maintenance Cost | Lower — single license, centralized user management | Higher — duplicate licensing, duplicate Release management |
| Customer 360 and Unified View | Native — all data in the same query space | Requires a dedicated BI layer or integration |
| Operational Autonomy per Unit | Limited — every Release affects everyone | Full — each unit controls its own pace |
| Adherence to Strict Regulatory Separation Requirements | Not possible if the requirement is physical separation | The only option that meets the requirement |
| Inter-Unit Integration Complexity | Low | High — requires Middleware or ETL |
| Risk in Future Mergers/Splits | Low — permission changes only | High — full migration project |

The bottom line: the default should be a single Org, and a split should only be chosen when there is a clear and affirmative answer to one of the three questions above, not as a response to temporary organizational friction.

## What Actually Happens When You Split Without Sufficient Cause

When an organization splits an Org for political reasons (a unit wanting "its own control") rather than genuine technical reasons, three things happen within one to two years: First, duplicate customer records are created in every Org where the same business entity appears, without a common identification key. Second, any organization-level change (such as updating a security process or implementing a new tool) becomes a separate project in each Org, doubling the cost of every future change. Third, company-wide reporting requires an integration layer that was not needed in the first place, and often this is built under pressure after the problem is discovered, rather than as part of the initial planning.

Therefore, one of the guiding principles in [Salesforce Architecture](/en/insights/crm-architecture-guide) is to first examine whether the organizational need can be met with permissions and Sharing Rules within a single Org, and only then consider a split.

## A Phased Approach for Those Already Needing to Split

When one of the three tests indeed applies, the split should be carried out in a sequence that minimizes risk:

### 1. Define a Global Identifier Before the Split

Before creating a second Org, establish a standardized identifier field (company ID, global Customer ID, or similar code) that will enable future record matching between environments. Without this, any future attempt to unify a customer view will rely on name and address matching, which generates errors at scale.

### 2. Choose an Integration Pattern Based on Data Flow and Velocity

If it's for periodic updates for reporting purposes only, a scheduled ETL is sufficient. If real-time visibility is required (e.g., cross-unit credit checks), a synchronous API with error handling and retry mechanisms is needed. Choosing the wrong pattern is the main reason cross-Org integrations break under load — more details on this topic in [Salesforce Integration Patterns](/en/insights/salesforce-integration-patterns).

### 3. Plan Identity and Access Permissions in Advance

Users working in both Orgs (e.g., global account managers) require an Identity solution managed once, not two separate users with two passwords. Planning SSO between Orgs prevents a situation where every user permission change is manually performed in two environments — this topic is detailed in [Salesforce SSO and Identity Architecture](/en/insights/salesforce-sso-identity-architecture).

### 4. Test API Limits Before Integration Goes Live in Production

Every call between two Orgs counts towards the API quota of both sides. Traffic planned without volume testing can hit daily limits precisely at peak load, which is exactly when the integration is most needed. This should be tested beforehand against [Salesforce API Limits](/en/insights/salesforce-api-limits-resilience).

### 5. Define an Owner and Joint Governance Process for Both Orgs

Someone needs to be responsible for the consistency of architectural decisions between environments — field structure, naming conventions, and change policies. Without central ownership, both Orgs will diverge in terms of standards within a year, making any future integration more expensive.

## Illustrative Scenario: Insurance Group with Two Divisions

This scenario is hypothetical and for illustration purposes. An insurance group had a general insurance division and a life insurance division, both operating under the same legal entity but with different regulators and entirely different product approval cycles. The life insurance division required strict change control with regulatory approval for each Release, while the general insurance division wanted to release improvements weekly.

The initial suggestion was to split into a separate Org for each division, but upon review against the three questions, it became clear that only the regulatory pace (Test 2) truly applied — the customer and product model did not conflict (Test 3 was negative), and there was no requirement for physical data separation (Test 1 was negative). The chosen solution was a single Org with two separate "release tracks" within the same environment — a dedicated Sandbox and a separate approval process for the life insurance division, while using a shared data model for a unified Customer 360. The full split was avoided, as was the dual maintenance cost that would have been incurred for years.

## Common Risks and How to Prevent Them

-   **"Temporary" split that becomes permanent** — A Sandbox that turns into a production environment without undergoing security auditing. Prevent this by ensuring every Org with real customer data undergoes a formal Governance approval process, without exception.
-   **Duplicate records without a common key** — Occurs when the split happens before a global identifier is defined. Prevent this by establishing the common field as a prerequisite for the split, not as a later step.
-   **API quota exhaustion during peak load** — Happens when inter-Org integration is planned based on average volume rather than peak volume. Prevent this by load testing before going live and building a backoff mechanism.
-   **Standard drift between Orgs** — Occurs when there is no single owner for the shared architecture. Prevent this by establishing a small Governance committee that approves data structure changes across both sides.
-   **Unreliable management reporting** — Happens when attempting to calculate cross-organizational KPIs directly from Salesforce without a consolidation layer. Prevent this by setting up a dedicated BI layer from day one of the split, not as a late rectification project.

## Summary

A single Org is the default; splitting is an exception that requires concrete justification in one of the three tests — genuine regulatory independence, incompatible pace of change, or a physically conflicting data model. When justification exists, the success of the transition is measured by the preparation undertaken before the split: a global identifier, appropriate integration pattern, shared identity, API limit testing, and clear ownership of shared standards. An organization that skips this preparation doesn't save work — it merely postpones it to a moment when the fix is far more expensive.

### Questions and answers
**Is a company merger sufficient justification for a multi-org Salesforce strategy?**
Not automatically. If both companies will operate under separate brands and sales processes for an extended period, a distinct Org is worth considering. However, if the plan is to unify processes within one to two years, it's often better to temporarily consolidate under a single Org with permission-based segregation. This approach avoids the significant costs of a reverse merger later on.

**How can we achieve consolidated reporting with multiple Salesforce Orgs?**
Typically, this is accomplished via an external Business Intelligence (BI) layer, such as Data Cloud, Snowflake, or Tableau. This BI solution pulls data from each Org independently and unifies it into a single reporting model. Attempting to build cross-Org reports directly within Salesforce almost always requires expensive integration work that rarely delivers equivalent value.

**What happens if a customer exists in two different Salesforce Orgs?**
Without a defined matching process, the same customer will result in duplicate records in each Org, each with partial history. Before any split occurs, it's crucial to establish a shared external identifier (e.g., a global company ID or tax ID) and implement a synchronization process, or at least a periodic reconciliation report.

**Is it possible to merge two Salesforce Orgs back into one?**
Yes, but this is a full-scale migration project, not a simple configuration change. It requires aligning object models, record types, approval flows, historical data, and integrations across both environments. Often, a specialized migration tool is necessary. Therefore, consider a multi-org split as a difficult-to-reverse decision rather than an experimental, reversible step.

**What does 'accidental Multi-Org' mean?**
This common scenario occurs when a business unit opens a Sandbox or a separate Org for temporary experimentation, and it inadvertently evolves into a live production environment without a conscious decision. The tell-tale sign is the presence of real customer data in an Org that hasn't undergone full governance, security, and access control processes.

---

## Salesforce Data Mapping: Avoid Migration Errors Before You Load
URL: https://hpi.pro/en/insights/salesforce-data-mapping
Most Salesforce migration failures stem not from tool limitations but from meaning discrepancies: fields with identical names in two systems, yet describing different things. This guide walks you through building a data mapping document that captures business meaning, transformation rules, default values, and ownership – before your first data load.

## The Short Answer

Data mapping isn't a mere field-to-field translation spreadsheet; it's the definitive document where an organization decides the meaning of every data point it brings into Salesforce. Nearly every loading error that appears technical – incorrect date format, unrecognized picklist value, broken relationship – originates from an unmade business decision.

The effective process goes like this: First, determine which entities will be migrated. Next, identify the business owner for each entity. Then, define which fields have a genuine consumer. Only then should you write conversion rules. When the process starts in reverse, the technical team quietly makes business decisions, which only surface three months post-Go Live when a revenue report doesn't add up.

For background on overall migration planning, refer to [Salesforce Data Migration Guide](/en/insights/salesforce-data-migration-guide).

## Three Types of Gaps Data Mapping Reveals

| Gap Type | Common Example | Decision Maker |
|---|---|---|
| Semantic Gap | "Active customer" = purchased this year in one system, = not blocked in another system | Business Process Owner |
| Structural Gap | One customer with five addresses versus an Account/Contact model | Data Architect |
| Quality Gap | 18% of records without a valid tax ID | Data Owner + Regulation |

The semantic gap is the most costly because it doesn't cause loading failures. The data successfully loads, automation runs on it, and reports show inaccurate yet plausible numbers. Structural gaps cause load failures and are therefore discovered early. Quality gaps are only discovered if acceptance thresholds are defined in advance.

## The Layer of Meaning: Data Dictionary Before Mapping Spreadsheet

Before mapping field to field, create a data dictionary that defines key entities: what an Account is, what differentiates a Lead from a Contact in this organization, and when an Opportunity closes. These definitions are concise – two lines per entity – but they enable dispute resolution by decision, not by vote.

The simple test: Ask three people from three different departments to define "customer" independently. If the definitions vary, the migration will transfer three different truths into the same table.

## Anatomy of a Proper Mapping Row

Each row in the spreadsheet should answer seven questions: from which source object and field, to which Salesforce object and field, what is the data type and length, what is the conversion rule, what happens with a blank value, what is the default value, and who approved it. A row missing any of these columns will resurface as a question during a late-night cutover load.

Three operational rules that prevent issues:

- **No silent conversions.** Any value the system "corrects" automatically must be logged as an exception.
- **Default values are business decisions.** The person setting `Country = IL` as a default should be accountable for region-based reports.
- **External IDs before anything else.** For each entity, retain an External ID from the source system. Without it, there's no reconciliation and no second run.

## Transformations: Where Mistakes Occur

The transformations that cause the most damage are often the simplest ones. Dates without time zones shift records by a day; names that are trimmed and capitalized inconsistently create new duplicates right after old ones were cleaned; amounts converted to a uniform currency at a daily exchange rate lead to reporting discrepancies with the ERP.

Rule: All numerical or monetary transformations are validated by comparing totals, not by comparing individual records. Identical counts do not confirm accuracy.

For those still pondering the source of truth, refer to [Source of Truth in the Organization](/en/insights/salesforce-source-of-truth), and for the cutover window itself, see [Cutover and Reconciliation](/en/insights/salesforce-migration-cutover-reconciliation).

## Scenario: Service Company with Two Source Systems

A service organization with 90,000 customers undertook a migration from two systems: an older billing system and a service system acquired with a subsidiary. The first mapping spreadsheet was marked "ready" within two weeks—340 fields mapped.

During the first rehearsal run, 97% of records were loaded. The issue emerged during reconciliation: the total balances in Salesforce were 4.1% lower than in the ERP. The reason wasn't a failed load, but rather that all records with negative balances (credits) were mapped to a field with a validation rule preventing negative values—and were silently set to zero.

The fix involved two levels: an explicit conversion rule for credits, and a policy change requiring any rule that zeroes out or truncates a value to generate an exception record. In the second run, the number of exceptions rose to 1,900, which was progress: the exceptions were visible instead of hidden. The third run reduced exceptions to 40 documented cases, and only then was the cutover date set.

## Common Risks and Prevention Actions

| Risk | How it Appears in Practice | Prevention Action |
|---|---|---|
| Migrating all history | Volume, duplicates, and valueless data transfer to the new system | Define retention and quality thresholds |
| Technical mapping only | Fields are transferred without understanding business meaning | Data Dictionary and business owners |
| Silent conversions | Values are automatically corrected, and no one knows | Mandatory exception logs for all conversion rules |
| No rehearsal | Cutover window expands and surprises occur | At least two full runs |
| No External ID | Unable to verify, correct, or rerun | Source key retained for each entity |

## How to Measure Success

| Area | What to Measure | Check Frequency |
|---|---|---|
| Completeness | Percentage of mandatory fields populated in target | Before and after each load |
| Reconciliation | Matching counts, sums, and relationships to source | Each rehearsal and at cutover |
| Exceptions | Number of open exception records by severity | Daily during migration period |
| Fields without consumers | How many migrated fields were not accessed in 90 days | Once after Go Live |

The last metric prepares for the next cycle: it shows how much effort was unnecessary and guides the scope of future migrations.

Organizations preferring professional guidance in building their mapping do so as part of [Integrations and Data Services](/en/integrations-data).

## Checklist Before the First Load

- ☐ Concise data dictionary for each key entity, approved by business
- ☐ List of fields with a defined consumer; others for archiving
- ☐ External ID for every entity being migrated
- ☐ Complete value mapping table, including handling of unrecognized values
- ☐ Explicit rule for every blank value and every default value
- ☐ Every conversion rule generates an exception record instead of a silent correction
- ☐ Reconciliation script: count, sum, relationship, manual sampling
- ☐ Agreed-upon exception threshold above which cutover will not proceed
- ☐ Version and sign-off on the mapping spreadsheet
- ☐ Rollback plan and rerun procedure

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**What's the difference between technical and business mapping?**
Technical mapping answers, 'Which field does this go into?' Business mapping answers, 'What does this field mean, who updates it, and what happens if it's empty?' Two systems might both have a 'Status' field – one for sales stages, another for collection status. Only business mapping reveals this critical difference before the load.

**How many fields do we actually need to migrate?**
In projects we've led, 40-60% of fields in source systems are either not actively used or can be re-derived. The practical rule: only migrate a field if it has a defined consumer—a process, report, automation, or regulatory requirement. Fields without a consumer belong in an archive, not in Salesforce.

**Where should transformation rules be documented?**
In a single, version-controlled mapping spreadsheet where each row includes: source, target, type, transformation rule, default value, empty value handling, and the business owner who approved it. If the rule only lives in an ETL script, no one in the business can approve it, and it can't be reconciled.

**What do you do with non-matching Picklist values?**
Create a separate Value Mapping table with a comprehensive mapping, including a default value for unrecognized entries. The rule: no source value is left without a target, and no unrecognized value is quietly loaded. It must trigger an exception report that someone resolves before cutover.

**When is data mapping considered 'ready'?**
When a full rehearsal run has passed, with reconciliation that verifies counts, sums, and parent-child relationships. The remaining exception list must be below the pre-agreed threshold and formally approved in writing by process owners.

---

## Pre-Salesforce Deduplication Strategy: A Practical Guide to Data Cleansing
URL: https://hpi.pro/en/insights/salesforce-data-deduplication
Data duplication isn't just a data glitch; it's an identity crisis. Your organization hasn't clearly defined what makes two records represent the same customer. This guide reveals how to establish robust matching rules, construct a 'Golden Record,' decide what to merge vs. what to archive, and critically, how to prevent duplicates from reappearing weeks post-migration.

## The Short Answer

Deduplication fails when treated as a one-time cleanup. It's actually three decisions: what defines identity, who wins when there's a conflict, and how to prevent the problem from recurring. The technical tool is the easy part.

The common mistake is to run Fuzzy Matching on names, get a list of 12,000 potential matches, and try to manually resolve them under time pressure. What works is the opposite: first narrow down the decision space using strong keys, and leave only the gray area for human review.

The broader migration plan is described in [Salesforce Data Migration Guide](/en/insights/salesforce-data-migration-guide).

## Three Layers of Matching

| Layer | What it relies on | Action |
| --- | --- | --- |
| Strong Key | Company ID, VAT ID, source system ID, verified email | Automatic Merge |
| Complex Key | Normalized Name + City + Normalized Phone | High-score Automatic Merge |
| Textual Similarity | Name only, free-text address | Human Review Only |

A well-managed project typically looks like this: approximately 70% of duplicates are resolved in the first layer, about 20% in the second, and 10% reach a human. If most matches end up in the third layer, it's a sign that normalization wasn't thoroughly implemented—not necessarily that the data is exceptionally poor.

## Normalization Before Comparison

Before any comparison, create normalized helper columns without altering the original data: remove corporate suffixes (Ltd., Inc.), standardize spaces and apostrophes, format phone numbers to E.164, convert email to lowercase with plus tag removal, and split addresses into street/number/city. For Hebrew, add handling for full/missing vowels and acronyms.

Normalization alone typically reduces one-third to one-half of "hard" duplicates even before applying any similarity algorithm.

## Golden Record at the Field Level

The decision of "which record survives" isn't the critical one. The critical decision is "which value survives in each field." Establish a concise policy: billing details from the ERP, contact information from the system where the last activity was recorded, customer status from the operational system. Each field should have one preferred source, and any rejected values should be documented.

Without such a policy, every merge becomes a decision made by the person performing it at that moment—and it's impossible to explain later why an address disappeared.

## What Happens to Relationships and History

Merging records affects Activities, Opportunities, Cases, Files, and Permissions. Before a bulk run, explicitly define: where activities go, what happens to open opportunities for the same customer from two records, and who the owner is after the merge—because changing the Owner also impacts visibility and commission reports.

The practical rule: no merging before a reproducible "what changed" report exists, and source identifiers are preserved in a separate field to allow for investigation months later.

## Scenario: Importer with 210,000 Contacts

A B2B importer began a migration with 210,000 Contacts from three systems. The first run of a similarity tool returned 31,000 suspicious pairs—a number no one could review.

The team stopped and reversed the order. First, email and phone were normalized: 14,000 pairs were automatically resolved by a strong key. Then, it was determined that the business unit was a customer site, not a corporation, which removed 6,000 legitimate pairs from the list—separate branches of the same chain. This left 4,200 pairs for the intermediate layer, of which 3,800 were resolved with a high score. 400 pairs reached human review, and two people resolved them in three days.

The lesson wasn't about tool selection. It was that defining the business unit—site versus corporation—reduced more noise than any algorithmic improvement.

## Prevention: Why Duplicates Return

Three main sources cause duplicates to return after Go Live: manual entry without active Matching Rules, integrations that create new records instead of updating (Upsert on External ID solves most of these), and Web-to-Lead forms without existence checks. If these three aren't addressed, the duplicate rate will return to its original level within one to two years.

## Common Risks and Prevention Actions

| Risk | How it appears in practice | Prevention Action |
| --- | --- | --- |
| Aggressive Merge | Different customers merged and cannot be separated | High score threshold + gray area review |
| No Identity Definition | Recurring debate over what constitutes the same customer | Documented entity-level decision |
| History Loss | Activities and opportunities disappeared during merge | "What changed" report and preservation of source IDs |
| Cleanup without Prevention | Duplicates return within months | Matching Rules, Upsert, and protected forms |
| Cleanup After Load | Every merge touches live relationships | Clean in the Staging phase |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Uniqueness | Estimated duplicate rate per entity | Weekly during migration, quarterly afterwards |
| Merge Accuracy | Percentage of merges undone or manually corrected | With each merge wave |
| Prevention | New records blocked as duplicates during entry | Monthly |
| Business Impact | Duplicate customer outreach, accuracy of customer reports | Quarterly |

Professional guidance in building identity and prevention rules is available through our [Integrations and Data Services](/en/integrations-data).

## Checklist Before Running a Merge

- ☐ Business unit defined: company, site, or contract
- ☐ Normalization columns built without altering source
- ☐ Three layers of Matching with written numerical thresholds
- ☐ Field-level Golden Record policy, business-approved
- ☐ Decision made on what happens to activities, opportunities, and ownership
- ☐ Source IDs preserved after merge
- ☐ "What changed" report can be generated and reverted
- ☐ Trial run on a sample with manual verification
- ☐ Matching Rules and Upsert active for prevention
- ☐ Permanent owner for the process after Go Live

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**What constitutes a duplicate, and what doesn't?**
This is a business decision, not merely technical. Two branches of the same corporation might be legitimate separate records for sales, but a single record for billing. Before running any deduplication tool, you must define the core entity: Is your business unit the corporation, a specific site, or a contractual agreement?

**Should we cleanse data before or after loading into Salesforce?**
Always cleanse BEFORE. A duplicate record loaded into Salesforce already creates relationships – activities, cases, opportunities. Any late-stage merge becomes a risky operation with potential history loss. Post-load, your focus should shift to ongoing enforcement, not large-scale cleanup.

**What if two records hold different, yet equally valid, information?**
Build a 'Golden Record' at the field level, not just the record level. For each field, define a precedence rule: preferred source system, most recent update, or a validated value. This ensures you don't lose a correct address simply because the 'winning' record had an outdated one.

**Are Salesforce's native Matching Rules sufficient?**
Salesforce's native matching rules are excellent for ongoing prevention during manual data entry, but they're typically insufficient for historical data cleanup before a major migration. Initial cleanup requires a dedicated tool or script capable of fuzzy matching on normalized text, allowing for human review of 'gray area' records before merging.

**What's a 'normal' percentage of duplicates?**
In older, unmanaged databases, it's common to see 8-20% duplication at the Contact level and 3-10% at the Account level. The practical goal isn't zero, but an agreed-upon threshold – for example, below 2% – supported by a process to prevent regression.

---

## Mastering Your Enterprise Data: Who Owns Customer, Product, Order, and Payment?
URL: https://hpi.pro/en/insights/salesforce-source-of-truth
Without clear data ownership, every integration becomes a negotiation, leading to systems overwriting each other. This guide reveals how to establish a Source of Truth for every field, differentiate between display and authoritative systems, and enforce these decisions through code, not just documentation.

## The Short Answer

Source of Truth isn’t a technical question; it’s a question of authority: who within the organization is authorized to declare a particular value as correct. When this decision isn't made explicitly, it's made silently—by whoever wrote the last integration.

The core principle: ownership is determined at the field level, not the system level. The attempt to declare "the ERP is the source of truth for the customer" breaks the moment the Service department updates a phone number in Salesforce, and the nightly sync erases that update.

## Three Questions That Determine Ownership

For each entity, and then for each group of fields, ask: where was the data **first created**, who is **business-authorized** to change it, and who **bears responsibility** when it's incorrect. In all three cases, the answer should be a job title, not a system name. The system is derived from the role.

When the answers point to two different roles, it's almost always a sign that two distinct fields have been compressed into one.

## Example Ownership Matrix

| Entity / Field | Source of Truth | Salesforce | Sync Direction |
| --- | --- | --- | --- |
| Legal Name, Company ID, Payment Terms | ERP | Read-only | ERP ← Salesforce |
| Contact, Title, Preferences | Salesforce | Editable | Salesforce ← Marketing Systems |
| Product Catalog & Base Price List | ERP / PIM | Read-only | ERP ← Salesforce |
| Quote & Approved Discount | Salesforce | Editable | Salesforce ← ERP |
| Approved Order & Delivery Status | ERP | Read-only | ERP ← Salesforce |
| Outstanding Balance & Collection Status | Financial System | Read-only | Financial ← Salesforce |
| Activities, Cases, and Communication | Salesforce | Editable | No Outbound Sync |

This table is the deliverable. It's concise, it resides in a single document, and every new integration is vetted against it before being written.

## Separating Presentation from Authority

Much of the tension between systems disappears when you understand that presenting data doesn't require copying it. An outstanding balance displayed to a salesperson doesn’t have to be a field in Salesforce that updates nightly; it can be a remote view or a federation layer.

Every copied field is an operational commitment: sync, failure, discrepancy, and time. Before copying, ask if automation or historical reporting is required on it. If not, it's better to present than to copy. An expansion on this approach can be found in [Zero Copy and Federation in Data 360](/en/insights/data-360-zero-copy-federation).

## Conflicts: Decide in Advance, Not in Real-Time

Even when ownership is clear, situations of concurrent updates arise. Three possible rules: system precedence (the owner always wins), last timestamp, or flagging for manual intervention. The third rule is the safest for sensitive fields—provided there’s a processing queue with an owner, not just a sinking log entry.

## Scenario: Organization with Two Truths for One Address

An infrastructure services company managed customer addresses in two systems: ERP for invoicing and a Field Service system for technician dispatches. Both were bi-directionally synced to Salesforce. The result: an address that flipped back and forth, and technicians arriving at a billing address.

The solution wasn't fixing the sync but decomposing the entity. Two separate fields were defined—billing address owned by the ERP, service address owned by the field system—both read-only in Salesforce, with a link to a change request routed to the correct owner. The number of service calls closed as "incorrect address" significantly decreased in the following quarter.

The lesson: when systems "fight" over a field, it often means two different business data points were given the same name.

## Enforcement: From Document to Reality

An ownership matrix only exists if it’s enforced at three points: Field-Level Security that prevents editing on the non-owning side, an integration user with restricted permissions to only their owned fields, and a monthly report that shows fields updated contrary to policy. The third report reveals forgotten legacy integrations.

Documenting the meaning of each field directly connects to [Data Mapping for Migration](/en/insights/salesforce-data-mapping).

## Common Risks and Preventive Actions

| Risk | How it Manifests in Practice | Preventive Action |
| --- | --- | --- |
| System-level ownership | Contradictions within the same entity | Decision at the field or field group level |
| Bi-directional sync as default | Values intermittently flipping | One-way sync + read on the other side |
| Unnecessary copying | Dozens of synced fields without a consumer | Present instead of copying |
| Document without enforcement | Policy erodes within months | Field permissions + anomaly monitoring |
| No conflict queue | Discrepancies quietly accumulate | Processing queue with owner and SLA |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Consistency | Discrepancy rate in key fields between systems | Monthly |
| Policy Violations | Writes to a field outside the defined owner | Monthly |
| Conflicts | Number and resolution time of items in queue | Weekly |
| Operational Impact | Incidents caused by incorrect data | Quarterly |

Building and enforcing an ownership matrix is carried out within our [Integrations & Data service](/en/integrations-data).

## Source of Truth Decision Checklist

- ☐ List of key entities in the organization
- ☐ For each entity: where created, who is authorized, who is responsible for errors
- ☐ Ownership determined at the field or field group level
- ☐ Explicit sync direction for each group
- ☐ Every copied field stands the "it has a consumer" test
- ☐ Conflict resolution rule selected and documented
- ☐ Manual processing queue with owner and SLA exists
- ☐ Field-Level Security aligns with the matrix
- ☐ Integration user limited to owned fields
- ☐ Monthly report for policy violations

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data

### Questions and answers
**Can multiple systems be the Source of Truth for the same entity?**
For the same entity, yes; for the same field, no. Billing details might be owned by your ERP, while contact information and activity history are owned by Salesforce—both for the same customer. What's crucial is preventing two systems from writing to the same field without a clear arbitration rule.

**What's the difference between a System of Record and a System of Engagement?**
A System of Record is authoritative for determining a value; a System of Engagement is where people interact with and work with that data. Salesforce often acts as a System of Engagement for customer data, and also as the System of Record for the sales pipeline and customer interaction history. Confusing these two roles commonly leads to unnecessary bi-directional synchronization.

**When is bi-directional synchronization justified?**
Only when both systems genuinely add value to the same field, and there's an unambiguous arbitration rule—such as a timestamp or system precedence. In all other cases, prefer a single direction with a read-only view in the secondary system. Bi-directional sync inherently multiplies potential failure points.

**How do you enforce data ownership in practice?**
Through three layers: field permissions that prevent editing by non-owners, integrations that only write to fields they own, and monitoring that flags unauthorized writes. An ownership document without technical enforcement will inevitably degrade over months.

**What if no single system seems suitable as a Source of Truth?**
This often indicates the entity is defined too broadly. Break it down: a 'Product' might split into a catalog (ERP), a commercial offer (CRM), and usage authorization (operational system). Each distinct component can then have a clear Source of Truth.

---

## Salesforce Data Quality Metrics: What to Measure & How to Set Baselines
URL: https://hpi.pro/en/insights/salesforce-data-quality-metrics
Data quality only truly becomes manageable when it's quantifiable, has clear thresholds, and assigned ownership. This guide outlines which dimensions are genuinely worth tracking in Salesforce, how to establish non-arbitrary baselines, how to connect each metric to a business impact, and how to build a data quality scorecard that actually gets reviewed more than once.

## The Short Answer

Data quality isn't an inherent attribute of data; it's a result of processes. Therefore, measurement that isn't tied to a business impact and assigned an owner changes nothing. Instead, it generates a report someone briefly reviews quarterly and gives a nod of approval.

An effective "Scorecard" consists of only four to six metrics, each with a defined threshold, an owner, and a corrective action. The difference between a Scorecard and a report is that with the former, every red number triggers someone into action.

## The Five Dimensions — And What They Truly Measure

| Dimension | What it Checks | When it's Critical |
| --- | --- | --- |
| Completeness | Percentage of filled fields that drive decisions | Always |
| Validity | Conformance to format rules and valid values | Integrations, Regulations |
| Uniqueness | Duplication at an entity level | Before migration and after mergers |
| Timeliness | How current data is compared to reality | Forecasting, Service, Collections |
| Consistency | Whether the same data is identical across systems | Multiple systems and financial reporting |

Organizations almost always begin with the first three. Timeliness and Consistency become relevant when additional systems rely on the CRM – and that's precisely when failure in these areas becomes most costly.

## Completeness: Not Every Field Is Worth Measuring

Measuring the fill rate for 300 fields produces a meaningless number. The correct approach is to define a small "field package" for each main process – five to eight fields without which the process cannot function – and measure only those.

It's crucial to also include artificial completion checks: the percentage of records where a field was suspiciously filled with a repetitive value (e.g., a dot, a dash, "unknown"). This is often the first sign that a defined rule is hindering work rather than improving it.

## Timeliness: The Dimension Everyone Skips

Data can be complete, valid, and unique – and simply no longer accurate. A customer status field untouched for 14 months isn't data; it's a memory. Measurement is simple: the distribution of time since the last update for critical fields, compared to how quickly reality genuinely changes.

In sales opportunities, this directly translates to forecast quality: the percentage of open opportunities whose close date has already passed is one of the strongest and fastest-to-calculate metrics.

## From Threshold to Action: What Happens When a Metric Is Red

For each metric, three levels are defined – Green, Amber, Red – and an action for each level. Amber triggers a team review; Red triggers a correction with a target date. Without such a definition, the metric becomes information rather than a management tool.

The actions themselves should be varied: sometimes the correction is a one-time cleanup, sometimes a change in workflow, and often the right solution is to remove the field altogether – because no one actually needs it.

For additional background on duplicates, see [Salesforce Data Deduplication](/en/insights/salesforce-data-deduplication), and on structure that generates quality, see [Salesforce Data Model Design](/en/insights/salesforce-data-model-design).

## Scenario: An Insurance Company That Measured Everything And Improved Nothing

An insurance company built a quality dashboard with 34 metrics. It ran for a year. No metric significantly improved because there was no ownership: the dashboard belonged to the BI team, and the fields belonged to agents.

In the second stage, the dashboard was narrowed to four metrics: the fill rate for the signing field package, the percentage of policies with an overdue renewal date, the duplication rate at the insured level, and the percentage of failed email deliveries. Each metric was assigned a regional manager with a quarterly target, and the metrics were presented in sales meetings, not IT meetings.

Within two quarters, two metrics crossed their thresholds. The third metric didn't budge – and investigation revealed that the field was required on a form agents filled out after closing a deal, i.e., at a time when they had no incentive. The solution was a change in the process's placement, not an additional validation rule.

## Common Risks and Preventive Actions

| Risk | How it Appears in Practice | Preventive Action |
| --- | --- | --- |
| Too many metrics | A dashboard no one acts upon | Four to six metrics with owners |
| Metric without a threshold | Debate over "is 78% good?" | Threshold derived from business impact |
| Ownership by IT | No behavioral change in the field | Business owner for each metric |
| Validation without measurement | Fields filled with dummy values | Measuring artificial completion |
| One-time measurement | Temporary improvement that regresses | Regular, periodic Scorecard |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Completeness | Fill rate for process field package | Monthly |
| Timeliness | Median time since last update | Monthly |
| Uniqueness | Estimated duplication rate | Quarterly |
| Impact | Complaints, integration failures, forecast accuracy | Quarterly |

Scorecard building and operational process are conducted as part of our [Integrations and Data Service](/en/integrations-data).

## Checklist for Establishing Measurement

- ☐ No more than six metrics selected
- ☐ Each metric has a defined field package, not the entire object
- ☐ Each metric has a threshold derived from business impact
- ☐ Each metric has a full-name business owner
- ☐ Actions defined for Amber and Red levels
- ☐ Artificial completion is also measured, not just completeness
- ☐ Baseline established before improvement begins
- ☐ Report presented in a business forum, not technical
- ☐ Checked whether a problematic field is actually necessary
- ☐ Periodic review for the list of metrics itself determined

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**Which data quality dimension should I start with?**
Begin with 'Completeness' on a small, high-impact set of fields that drive critical business decisions—not every single field. Fill rate is the easiest dimension to calculate, the simplest to explain to leadership, and often quickly illuminates broken processes.

**How do you set a non-arbitrary data quality threshold?**
Derive it from its business implication. If 5% of emails are incorrect and a campaign generates 200 leads monthly, you can translate that into a projected loss. The threshold should be set where the cost of remediation begins to outweigh the damage, not at an arbitrary round number that 'sounds good'.

**Who is responsible for a data quality metric?**
The owner of the business process that creates the data, not the data team. The data team measures and provides tools, but the sales rep, accounts receivable clerk, or service agent causing the data discrepancy is the one who can change the behavior that creates the gap. A metric without business ownership will not improve.

**Do Salesforce Validation Rules solve data quality issues?**
Partially. They prevent incorrect values during manual entry but often push users to fill in *any* value just to progress. A validation rule must be accompanied by a metric that checks whether the field was genuinely completed or artificially populated (e.g., with 'N/A' or dummy data).

**What is the right frequency for measuring data quality?**
During a data migration project, weekly is appropriate. For ongoing operations, monthly for most metrics and quarterly for executive reviews. Daily measurement of data quality almost always generates noise that no one acts upon.

---

## Agentforce for Customer Service: Smart Starting Scenarios
URL: https://hpi.pro/en/insights/agentforce-customer-service-use-cases
Not every customer interaction is ideal for an Agentforce rollout, and proper sequencing determines project success. This guide ranks common service scenarios by readiness, outlines prerequisites for each, and highlights tempting-but-risky scenarios that can erode trust early on.

## The Short Answer

In customer service, the difference between a pilot that expands and one that stalls almost always comes down to the initial scenario selection. A mature scenario is one that relies on a single, reliable data source, doesn't involve irreversible actions, and has sufficient volume to justify its maintenance.

The most tempting scenarios—handling a complaint, customer retention, credit decisions—are precisely those that demand judgment, sensitivity, and information from multiple systems. These come in phase three, not phase one.

A general decision framework for fitting use cases can be found in [Agentforce for Enterprises](/en/insights/agentforce-for-enterprises).

## Scenario Maturity Rating

| Scenario | Maturity | Requirements | Primary Risk |
| --- | --- | --- | --- |
| Status Inquiries | High | Single reliable field in CRM | Almost none; reversible error |
| Common Knowledge Questions | High | Up-to-date Knowledge articles for common scenarios | Citing outdated policy |
| Agent Assist During Call | High | Knowledge and Case history | Agent adopts incorrect answer |
| Routing and Classification of Inquiries | Medium | Consistent taxonomy of inquiry types | Incorrect classification prolonging resolution |
| Updating Details and Simple Actions | Medium | Precise permissions and limited Actions | Incorrect update in customer record |
| Scheduling, Cancellation, and Rescheduling | Medium | Stable integration with operational system | Integration failure with customer |
| Credits and Compensation | Low | Written policy, authority, and human approval | Financial exposure and customer precedent |
| Complaint Handling and Retention | Low | Contextual understanding, sensitivity, and complete history | Damage to brand and trust |

## Three Scenarios to Start With

Status inquiries are the best starting point. The customer asks where their order is, what the status of their request is, or when the technician will arrive. The answer relies on a single field, there's no write operation, and the volume is usually high. Success is also easily measured: did the customer receive an answer and not follow up again?

Common knowledge questions are the second scenario. Here, the challenge isn't the agent but the content. Therefore, the work begins by examining the twenty most frequent inquiries and ensuring that each has an approved and up-to-date article.

Agent assist is the most recommended scenario to start with when there are concerns. The agent suggests an answer, and the human agent approves or corrects it. Every correction is a learning input, and the external risk is zero. Organizations that begin here face external exposure with a real testing set instead of assumptions.

What's needed for the knowledge base to handle the load is detailed in [Knowledge Management for Agentforce](/en/insights/agentforce-knowledge-readiness).

## What to Postpone to a Later Stage

Credits and compensation require a written policy that, in most organizations, doesn't fully exist—it lives in the discretion of team leaders. Before the agent enters this domain, the policy must be written, and then it's discovered to be an organizational endeavor in itself.

Complaint handling requires an understanding of emotional context and complete history. Even when the technical answer is correct, the phrasing matters. This is an area where quick escalation is almost always preferable to attempting a solution.

Cross-system scenarios where information is scattered across three systems without a single source of truth—not because of an AI limitation, but because data discrepancies will be revealed here first and attributed as an agent failure.

## Escalation Rules That Must Be Defined

Four strict triggers: an explicit request to speak to a person, identification of a negative tone or escalation words, two failed attempts to answer the same question, and any inquiry touching on a predefined sensitive topic.

The transfer must preserve context. A customer forced to repeat everything to a human agent perceives the agent as an obstacle, and that's what they'll remember. A summary of the conversation, what was checked, and what was found should automatically transfer to the human agent.

Designing escalation paths within a channel ecosystem is detailed in [Omni-Channel and SLA in Service Cloud](/en/insights/service-cloud-omnichannel-sla).

## Scenario: A Contact Center That Swapped Pilots After Two Weeks

A consumer goods company planned to start with an agent handling return requests—the scenario with the most complaints. Within the first two weeks, it became clear that each request required checking warranty conditions in the ERP system, checking inventory, and making a decision that was actually based on a manager's discretion.

The pilot was moved to another scenario: responding to the status of an existing return. The same customers, the same domain, but relying on a single status field. Volume was high, the escalation rate low, and the contact center saw an immediate decrease in repeat inquiries.

Six months later, after the returns policy was written as an approved document, the original scenario returned to planning—this time with human approval for every return authorization. Order, not technology, was what enabled this.

## Risks and Prevention Actions

| Risk | How it Appears in the Contact Center | Prevention Action |
| --- | --- | --- |
| Starting with an Emotional Scenario | Complaints reaching management in the first week | Start with an information scenario, not a resolution scenario |
| No Path to a Human | Customer trapped in a loop of questions | escalate to an agent at any stage and hard triggers |
| Loss of Context in Escalation | Customer repeats the story to the agent | Automatic conversation summary transfer |
| Unwritten Policy | Inconsistent answers between cases | Write the policy before introducing the scenario |
| Too Many Scenarios Concurrently | No capacity to maintain and quality declines | Up to three active scenarios in the first year |

## Metrics in Service

| Metric | Definition | Frequency |
| --- | --- | --- |
| Containment | Percentage of inquiries closed without an agent and no repeat inquiry | Weekly |
| Repeat Inquiry Rate | Customers who followed up on the same issue within a week | Weekly |
| Time to Escalation | How long until transfer to a human when needed | Weekly |
| Channel Satisfaction | Comparison against a comparable human channel | Monthly |
| Agent Handling Time | Did assistance actually shorten the call | Monthly |

Containment without a repeat inquiry rate is a misleading metric. A conversation closed quickly because the customer gave up is counted as a success, and therefore, both metrics are always read together.

When guidance is needed in selecting scenarios and establishing escalation paths, [Agentforce and AI services](/en/agentforce-ai) is the practical next step.

## Checklist for First Scenario Selection

- ☐ Scenario relies on a single, reliable data source
- ☐ No irreversible action in the first version
- ☐ Monthly volume justifies ongoing maintenance
- ☐ Approved articles exist for its common scenarios
- ☐ Four escalation triggers are defined
- ☐ Transfer to an agent includes a conversation summary
- ☐ Agent clearly states it is not human at the outset
- ☐ Baseline containment and repeat inquiry rates are measured
- ☐ Maximum number of active scenarios concurrently is set

### Questions and answers
**What's the best Agentforce scenario to start with?**
Status inquiries. They're high-volume, rely on one or two CRM fields, don't require complex writing, and are easy to measure for success. Plus, customers are most forgiving in these interactions, expecting information rather than a complex resolution.

**Should we start with an internal agent for reps or a customer-facing agent?**
Internal, almost always. An internal agent allows your reps to identify and correct errors, minimizing the cost of early mistakes. The same error with a customer erodes trust and escalates quickly. Three to six months of internal testing builds the robust validation needed for external deployment.

**How should an Agentforce bot handle an angry customer?**
Identify and escalate immediately. Detecting negative tone or escalation keywords should be a strict rule, transferring the customer to a human without further interaction. An agent attempting to de-escalate an angry customer often creates the negative stories that derail projects.

**Should the Agentforce bot disclose it's not human?**
Yes, and it's often a regulatory requirement. Beyond that, it's practical: a customer who realizes mid-conversation they've been speaking with a bot feels misled. A brief disclosure at the start, along with a clear path to a human, significantly reduces complaints.

**How many Agentforce scenarios should be active simultaneously in the first year?**
One to three. Each scenario requires its own content, testing, and monitoring. Organizations that activate six at once often find they lack the capacity to maintain any of them properly. Successful expansion comes after the first scenario is stable for at least a quarter.

---

## Grounding and RAG in Agentforce: Connecting Your Agent to Reliable Knowledge
URL: https://hpi.pro/en/insights/agentforce-grounding-rag
An Agent doesn't hallucinate out of malice. Hallucinations occur when information sources are incomplete, contradictory, or unauthorized. This guide breaks down the Grounding layer: which sources to connect, how to chunk and tag content, how permissions are maintained during retrieval, and how to measure accuracy before your Agent interacts with a customer.

## The Short Answer

Grounding is the difference between an agent that quotes approved policy and one that formulates something that sounds correct. In Agentforce, the Grounding layer consists of four components built in sequence: which sources are declared as the source of truth, how content is chunked and tagged for retrieval, how user permissions are preserved at the moment of retrieval, and what happens when no suitable source is found.

Most failures we see in pilots are not model failures. They are failures of a knowledge base no one has owned for two years, of documents that were cut in the middle of a table, and of a lack of a fallback path. Therefore, the work begins with a content readiness assessment, not by writing instructions.

The broader context for choosing a use case appears in [Agentforce for Enterprises](/en/insights/agentforce-for-enterprises).

## The Four Layers of Grounding

| Layer | What's Determined Here | Sign It's Broken | Evidence It Works |
| --- | --- | --- | --- |
| Sources | Which repositories are declared as sources of truth and who owns them | Two conflicting answers to the same question | List of sources with Owner and review date |
| Representation | Chunking, Metadata, and tagging by product, language, and version | Retrieved chunk is unrelated to the question | Measured Recall on a known set of questions |
| Permissions | How user context restricts retrieval | Internal content appears in a customer's answer | Persona testing for each permission level |
| Transparency | Citations, Freshness, and Fallback path | Answer without source and without admitting lack of knowledge | Percentage of answers with valid citation |

## Layer 1: Declaring Sources of Truth

The first step is not technical. You take the twenty most frequently asked questions in the chosen process, and for each question, you identify where the correct answer currently resides. The result is almost always surprising: some answers are in a Knowledge article, some in a CRM field, some in a document held by a team lead, and some in the heads of two veteran people.

Every source brought in needs a named owner, an agreed-upon update frequency, and a last review date. A source without an owner becomes a source of outdated information within months, and the agent will continue to confidently quote it. Sources without owners stay out, even if they are rich in content.

The difficult decision is what not to connect. Email repositories, chat channels, and sales presentations seem like a goldmine but turn out to be a primary source of incorrect answers because they don't distinguish between a draft, a rejected proposal, and approved policy.

The fundamentals of cleaning and preparing the knowledge base are detailed in [Agentforce Knowledge Readiness](/en/insights/agentforce-knowledge-readiness).

## Layer 2: Chunking, Metadata, and Relevance

Good retrieval depends less on the model and more on how content is broken down. Cutting by a fixed number of characters destroys tables, step-by-step lists, and eligibility criteria—precisely the content from which accurate answers are derived. It's better to cut by structure: a subheading, a step in a process, or a table row kept intact with its context.

Metadata is what allows you to narrow the search space before the model even comes into play. Minimum tagging to require: product or service line, market or country, language, target audience (customer or internal), expiration date, and approval status. Without market and language tagging, an agent in a global organization will mix policies from two countries in the same answer.

Relevance testing is quantitative, not intuitive: Build a set of 50 to 100 real questions with the correct answer and source, and measure in how many cases the correct chunk appeared in the retrieval. A low Recall score indicates a representation issue, and addressing it is much cheaper than replacing a model or rewriting instructions.

## Layer 3: Permissions at the Moment of Retrieval

This is the layer that causes pilot failures during security reviews. The rule is simple: Retrieval must run in the user's permission context, not in the context of a broad integration account. If a piece of information was hidden from the user in the interface, it must also be hidden from the agent's answer.

In practice, three checks are required. First, a mapping between external source classification levels and Profiles and Permission Sets in Salesforce. Second, Persona testing: Run the same ten questions as an agent, manager, and external customer, and compare answers. Third, handling mixed content – a document that is mostly public but has one sensitive paragraph must be cut or not included.

In a public channel, the safe default is a whitelist: only content explicitly marked as approved for the customer is added to the index available to the external agent. A blacklist approach will always miss one document.

The responsibility model between the organization, Salesforce, and the model provider is detailed in [Agentforce Security and Shared Responsibility](/en/insights/agentforce-security-shared-responsibility).

## Layer 4: Citations, Freshness, and Fallback

These three mechanisms transform an agent from an opaque system into one that can be audited. A true citation points to the actually retrieved chunk, not to an article the model mentions in the text – this is the difference between evidence and decoration. The percentage of answers with valid citations is one of the few metrics a non-technical manager can read and understand.

Freshness requires a written SLA: pricing policies reviewed quarterly, service procedures semi-annually, regulatory content immediately upon change. Content past its expiration date should automatically be removed from the index, not remain until someone notices the error.

Fallback is the behavior most important to test before exposure to customers. The agent should explicitly state that it has no approved information and escalate, rather than formulating a plausible answer. A good test question: ask about a non-existent product and see if the agent invents service terms for it.

## Scenario: An Insurance Company with 900 Knowledge Articles

An insurance company wanted an agent to answer policy terms for contact center representatives. The first pilot failed: 40% of answers were incorrect or partial. Analysis showed the problem was entirely in the source layer – out of 900 articles, 380 hadn't been updated in over three years, and 60 of them contradicted newer articles on the same topic.

The team didn't touch the model. They narrowed the index to three core products, only about 140 articles, assigned owners to each product line, and archived conflicting articles. They added tagging for product, version year, and approval status, and switched to chunking by section instead of fixed length.

The second round on the same set of 80 test questions achieved much higher accuracy, and importantly – in cases where there was no source, the agent escalated to a human instead of guessing. The conclusion that led to expansion was not "the AI improved" but "we know what it's based on."

## Risks and Precautionary Actions

| Risk | How It's Detected Late | Precautionary Action |
| --- | --- | --- |
| Conflicting sources | Different answers to the same question among representatives | Archiving old versions and a single source of truth for each topic |
| Chunking that breaks structure | Partial answers in multi-step processes | Chunking by section while preserving context heading |
| Permissions at integration level | Exposure of internal content on a customer channel | Retrieval in user context and Persona testing |
| No expiration date | Quoting policies that have been retired | SLA for updates and automatic removal from index |
| Undefined Fallback | Formulating a convincing answer without a source | "No approved information" path tested in every version |

## Metrics for the Grounding Layer

| Metric | Definition | Frequency |
| --- | --- | --- |
| Retrieval recall | Percentage of questions where the correct chunk is retrieved | Every version |
| Citation validity | Percentage of answers with an existing and valid source | Weekly |
| Content freshness | Percentage of articles in the index within their expiration date | Monthly |
| Fallback rate | Percentage of inquiries escalated to a human due to lack of source | Weekly |
| Permission leakage | Number of exposure findings in Persona tests | Every version |

A high Fallback rate is not a failure – it's a map of content gaps. The list of questions that led to Fallback is the best priority order for writing new articles.

When internal capacity for establishing a controlled Grounding layer is lacking, [Agentforce and AI Service](/en/agentforce-ai) is the practical path forward.

## Checklist Before Connecting an Agent to Sources

- ☐ Twenty most common questions mapped to their current answer source
- ☐ Every source in the index has a named owner and update frequency
- ☐ Conflicting sources identified and archived
- ☐ Tagging exists for product, market, language, audience, and expiration date
- ☐ Chunking preserves tables and step-by-step lists
- ☐ Retrieval runs in the user's permission context
- ☐ Persona testing performed for every relevant permission level
- ☐ Test set of 50 questions exists with correct answers and sources
- ☐ Citations refer to the actually retrieved chunk
- ☐ Fallback path is formulated and tested in the customer channel

### Questions and answers
**What's the fundamental difference between Grounding and RAG?**
RAG (Retrieval Augmented Generation) is a mechanism: retrieve relevant information snippets and append them to the prompt. Grounding is the business commitment that the retrieved information is from an approved, up-to-date, and authorized truth source for the specific user. You can implement excellent RAG on an outdated document repository and still get confidently incorrect answers.

**How many Knowledge articles do we need before getting started?**
Fewer than you might think. Twenty up-to-date articles covering the top ten common scenarios are better than a thousand articles where half were written four years ago. A contradictory article is more damaging than no article, as the Agent cannot decide between conflicting versions.

**Can we directly connect the Agent to SharePoint or Confluence?**
Technically, yes, via indexing or data connectors. The real question is permissions: if the external source's permission model cannot be mapped to the user in Salesforce, retrieval might expose content the user shouldn't see. In such cases, only synchronize a classified subset openly available internally.

**Why does the Agent return a generic answer even though the information is in an article?**
Often, this is a Chunking or Metadata issue, not a model problem. If an article is cut off in the middle of a table, or lacks tagging for product, country, and version, the retrieval might bring back an irrelevant snippet. A quick check: look at the Trace to see which snippets were actually pulled before blaming the model.

**What should happen when the Agent can't find a suitable source?**
A predefined Fallback path is crucial: an explicit statement that no approved information is available, and then handing off to a human or a form. An Agent crafting a plausible answer without a source is the main risk when deploying to customers, so this behavior must be thoroughly tested in every release.

---

## Human-in-the-Loop for Agentforce: Balancing AI Autonomy with Human Oversight
URL: https://hpi.pro/en/insights/agentforce-human-in-the-loop
Requiring human approval for every AI action negates its value; however, no oversight introduces risk. This guide outlines a methodology for establishing critical pause points based on reversibility, impact, and sensitivity. We explore three distinct approval patterns and define measurable criteria for removing approval gates without sacrificing control.

## The Short Answer

The question isn't whether to include a human in the loop, but precisely where. Approving every step eliminates savings and creates fatigue, leading to automatic sign-offs. Conversely, failing to require approval for irreversible actions results in the kind of incidents that reach executive management.

The practical approach begins by breaking down the process into individual actions, classifying each action by its reversibility and impact, and selecting an appropriate approval pattern—blocking, post-hoc, or sampling. Then, design the decision screen so that approval is a genuine judgment, not just a click.

The governance framework within which these decisions are made is detailed in [AI Governance for Agentforce](/en/insights/agentforce-ai-governance).

## Decision Matrix: Reversibility vs. Impact

| | Low Impact | High Impact |
| --- | --- | --- |
| **Easily Reversible** | No approval, monitoring only | Sampling of a percentage of cases for review |
| **Reversible at Cost** | Post-hoc review | Blocking approval before execution |
| **Irreversible** | Blocking approval before execution | Blocking approval + written justification + Audit trail |

Reversibility is measured by three questions: how long it takes to undo, how much it costs, and who is exposed before it's undone. A message sent to a customer is irreversible, even if a correction can be sent—the impression has already been made. Updating an internal field is reversible in a second and therefore doesn't warrant a stop.

## Three Approval Patterns

Blocking approval stops an action until a human decides. It is the most time-consuming pattern and is therefore reserved for irreversible or high-impact actions. The rule: if we stop, the human must receive everything necessary for the decision on a single screen.

Post-hoc review allows the agent to act and submit the result for review within a defined timeframe. Suitable for low-cost, reversible actions, it requires two conditions: a short timeframe and a genuinely functional undo button.

Sampling reviews a percentage of cases, not all of them. This is the correct pattern for high-volume, low-impact actions, and it also serves as a quality mechanism that later justifies removing a blocking approval elsewhere.

## Designing the Decision Screen

This is the part that determines whether the Human-in-the-Loop is genuine or merely formal. A screen that only displays the proposed action will receive automatic approval. A screen that requires opening three tabs for verification will cause delays and workarounds.

Four components should appear together: the proposed action in one line, the business-language explanation, the source the agent relied on with a link to the extracted section, and the confidence level or flags that were triggered. Below that, three options, not two: Approve, Reject with Reason, and Amend before Execution.

The reason for rejection is the most valuable asset in the process. It generates the training and testing set for the next version, so it should be a short list of common reasons, not an open text field that no one fills out.

How these decisions are monitored over time is explained in [Observability for AI Agents](/en/insights/agentforce-observability).

## Preventing Rubber Stamping

Approval fatigue is an expected failure, not a surprise. Three warning signs: average decision time drops below a few seconds, rejection rate approaches zero, and approvals are concentrated at the end of a shift.

The solution isn't training, but design. Reduce the number of approvals by removing unnecessary stops for reversible actions, add post-hoc sampling that creates accountability, and provide feedback to the approver on the quality of their decisions. When approvers know that a percentage of their decisions are reviewed, they start paying attention again.

Key metric: If the correction rate is zero for months, either the agent is excellent and approvals can be reduced, or no one is reviewing. Sampling distinguishes between the two.

## When and How to Remove an Approval Point

Removal is a data-driven decision, not a gut feeling. Three cumulative conditions: sufficient volume of documented decisions in the category, a consistently low correction rate for several consecutive months, and a genuinely tested undo or rollback mechanism.

Removal is staggered. First, to a narrow subset—for example, only amounts below a certain threshold, only customers in a specific segment, only during business hours. Then, measure for a month. Only then expand. Simultaneously, post-hoc sampling remains even after removal, otherwise there's no way to detect deterioration.

There also needs to be a rollback condition: if the error rate crosses a predefined threshold, the blocking approval automatically resumes. Without a written rollback condition, the decision to remove becomes irreversible itself.

## Scenario: A Service Center That Removed the Wrong Approval

A telecommunications company deployed an agent (Agentforce) that prepared responses to billing inquiries. In the first version, every response required agent approval, including simple status updates. Handling time decreased only slightly, and agents complained they were reading the same text repeatedly.

The team analyzed 4,000 approvals and found that 78% were for informational responses only—completely reversible and low impact. The correction rate in this category was below one percent. In contrast, the correction rate for credit adjustments was significantly higher.

The decision: Remove blocking approval for informational responses, with sampling of a percentage of them for weekly review; reinforce approval for credit adjustments and add a mandatory written justification above a certain amount. Handling time decreased significantly, and rejections in the credit adjustments category actually increased—a sign that approvers were paying attention again.

## Risks and Preventive Actions

| Risk | What it Looks Like | Preventive Action |
| --- | --- | --- |
| Approving Everything | Value is nullified, users bypass | Impact-Reversibility Matrix for every action |
| Automatic Sign-off | Decision time in seconds, zero rejections | Post-hoc sampling and personalized feedback for approver |
| Screen without Justification | Approver cannot truly judge | Display justification, source, and confidence level on one screen |
| Premature Removal | Production incident after a few good weeks | Measurable removal thresholds, phased expansion, and rollback conditions |
| No Rejection Documentation | Nothing to learn for the next version | Short list of rejection reasons and weekly review |

## Metrics

| Metric | What it Reveals | Frequency |
| --- | --- | --- |
| Stop Rate | Percentage of actions that required approval | Weekly |
| Correction Rate | Percentage of cases the approver changed or rejected | Weekly |
| Median Decision Time | Is the approver actually reading? | Weekly |
| Sampling Findings | Errors that passed approval | Monthly |
| Actual Undoing Time | Does the rollback mechanism work? | Per version |

For guidance in planning approval points and aligning them with regulatory requirements, the [Agentforce and AI Service](/en/agentforce-ai) is the practical path forward.

## Checklist

- ☐ Process broken down into individual actions
- ☐ Each action classified by reversibility and impact
- ☐ Approval pattern selected for each action: Blocking, Post-hoc, or Sampling
- ☐ Approver defined according to existing process authority
- ☐ Decision screen displays action, justification, source, and confidence level
- ☐ Option for amendment exists, not just approval or rejection
- ☐ Rejection reasons documented in a short list
- ☐ Measurable thresholds for approval removal and rollback conditions defined
- ☐ Rollback mechanism is practically tested, not just planned

### Questions and answers
**Doesn't human approval undermine the benefits of AI agents?**
Not when implemented strategically. The agent still handles data collection, analysis, and drafting – which consume most of the time. The human simply reviews and approves a prepped decision in seconds. Value is only lost if approval requires the human to re-verify everything the agent has done.

**Who should approve – the agent or the manager?**
Generally, the same individual who would approve the action without an AI agent. If a representative is authorized to issue credits up to a certain amount, they remain the approver. Escalation to a manager is only necessary when the amount or sensitivity exceeds their usual authority; otherwise, you create new bottlenecks.

**How can we prevent automatic 'rubber-stamp' approvals?**
Through three key strategies: display the rationale and source, not just the outcome; sample a percentage of approvals for post-hoc auditing; and monitor decision-making time. A series of approvals completed in under two seconds is a clear indication of automatic sign-off and necessitates a change in screen design or process.

**When is it safe to remove an approval point?**
When there's a sufficient volume of documented decisions, the rate of approver-initiated corrections is consistently low over several months, and a rapid reversal mechanism is in place. Removal should be staged – start with a narrow subset of cases, rather than the entire process at once.

**Can approval happen after the action, rather than before?**
Only when the action is quickly and cheaply reversible. Sending an internal email draft is suitable for post-hoc review; financial credits or messages sent to customers are irreversible and require prior approval, even if it slows the process.

---

## Sales Cloud Implementation: A Seamless Lead-to-Forecast Process
URL: https://hpi.pro/en/insights/sales-cloud-implementation
Sales Cloud implementations often falter, not due to technical misconfigurations, but because sales stages lack clear, measurable exit criteria. This guide showcases how to build a unified pipeline—Lead, Opportunity, Forecast—where each stage has quantifiable completion metrics, which is essential for a reliable sales forecast.

## The Short Answer

The difference between a successful and a failed Sales Cloud implementation almost always boils down to one question: Can it be stated, in a single sentence and without debate, what moves a deal from one stage to the next? When the answer exists, everything else – screens, fields, automations, and reports – flows from it. When it’s missing, you get a well-defined system that generates forecasts nobody trusts.

Therefore, the order of operations is: Define sales stages and exit criteria, followed by the data model, permissions, integrations, and finally, reports. Doing it backward – starting with a desired dashboard and working retrospectively – creates fields that are filled to make the report work, not to advance the sale.

## Where It Breaks Down in Practice

In a typical B2B organization, before intervention, you might see: 40% of pipeline opportunities with past due closed dates, a "Negotiation" stage that includes both initial conversations and contracts awaiting signature, and a sales manager maintaining a separate forecast spreadsheet because they don't trust the system. None of these issues are technical faults – they are all a result of undefined business rules.

## Sales Stages: Exit Criteria for Each Stage

The simple rule: A stage is defined by what the buyer has done, not by what the seller feels. "Customer is interested" is not a criterion. "Decision-maker identified and budget allocated" is.

| Stage | Measurable Exit Criterion | System Evidence | Probability |
| --- | --- | --- | --- |
| Qualification | Need, budget, and decision-maker identified | Budget and Decision Maker fields populated | 10% |
| Discovery | Customer-approved needs assessment presented | Linked document or Note | 25% |
| Proposal | Proposal with pricing and scope sent | Active Quote | 50% |
| Negotiation | Customer returned commercial or legal feedback | Activity logged in the last two weeks | 75% |
| Closed Won | Signature or PO | Attached file | 100% |

Probability is not a rep’s feeling but derived from the stage. The moment reps are allowed to manually override it, the forecast becomes subjective again.

## Lead vs. Opportunity: The Boundary That Determines Pipeline Quality

The most common mistake is automatically converting every inquiry into an Opportunity, usually to "make it look full." The result is a pipeline that triples in size and a closing rate that plummets, rendering any historical analysis worthless.

A working definition: A Lead remains a Lead until three conditions are met – an identified contact with authority, a need articulated in the customer's own words, and some kind of timeline. An inquiry that doesn’t meet these is managed as a Nurture Lead, not an opportunity. This also enables genuinely measuring the conversion rate between marketing and sales, instead of measuring the generosity of the conversion.

Those building the underlying data model can find background in [Salesforce Data Model Design](/en/insights/salesforce-data-model-design).

## Activities: Mandate Little, in Critical Places

Activity logging is where implementations lose rep trust. Mandating logging for every interaction is perceived as micromanagement, answered with minimal, valueless logging, and generates worse data than no logging at all.

The approach that works is to mandate logging at only three points: stage transitions, amount changes above a defined threshold, and closed date postponements. In each of these, the logging also serves the rep – it explains a decision they will be asked about in a meeting. Automated email and calendar sync cover the rest without requiring manual input.

## Forecast: What Needs to Be in Place Before Going Live

A reliable forecast requires four preconditions, and all behave like a chain – a missing link nullifies the rest:

1. **Correct User Hierarchy** - Forecast in Salesforce rolls up by Role Hierarchy, not by an organizational chart in a spreadsheet.
2. **Clean Closed Dates** - An operational rule that doesn't allow a deal to remain with a past-due date for more than a week.
3. **Defined Forecast Categories** - Pipeline, Best Case, Commit, Closed – with an agreed-upon definition of who moves a deal to Commit and when.
4. **Regular Review Cycle** - A weekly pipeline meeting conducted within the system, not from a parallel spreadsheet.

The last point is critical. As long as a shadow spreadsheet exists, reps know the system isn't the source of truth and update it belatedly.

## What to Measure After Go-Live

| Metric | What It Reveals | Problematic Threshold |
| --- | --- | --- |
| Forecast accuracy | Gap between Commit forecast and actuals | Deviation over 20% quarterly |
| Stage aging | Deals stuck in a stage | Over 2x the median |
| Update within 7 days | Does the system reflect reality? | Less than 70% of active opportunities |
| Data completeness | Mandatory fields in advanced stages | Less than 90% |

Deeper adoption metrics are detailed in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## What Not to Do in the First Wave

Complex Territory Management, multiple Forecast models, full CPQ, and automated Scoring are all capabilities worth adding – after the basic process is stable and two sales cycles have passed. Adding them in the first wave hardwires untested assumptions, making any future changes exponentially more expensive.

## Summary

Sales Cloud implementation is primarily a business definition exercise: when does a deal advance a stage, when does an inquiry become an opportunity, and what requires logging. These three decisions determine whether the forecast will be a management tool or a reporting exercise. The tool itself will support any definition you choose – including a poor one.

### Questions and answers
**How many Opportunity stages should we define?**
Typically, four to six. While more stages might seem precise, they often lead to ambiguous differentiation, causing reps to update them late or all at once before pipeline reviews, diminishing data accuracy.

**What's the practical difference between a Lead and an Opportunity?**
A Lead is an unproven inquiry; an Opportunity is a qualified potential deal with an identified buyer, a defined need, and a clear timeline. Automatically converting every inquiry inflates the pipeline and renders forecasts meaningless.

**Is mandatory activity logging always necessary?**
Enforcing blanket activity logging often generates formal, low-value data. It's more effective to mandate logging at critical decision points, such as stage transitions, amount changes, or closed-date postponements.

**When should we integrate CPQ or pricing tools?**
Only after your sales stages and product structure are stable. Integrating pricing into an evolving process multiplies change costs and entrenches temporary assumptions, making future adjustments more difficult.

**How long until our forecast becomes reliable?**
Typically, two to three full sales cycles post-go-live. Before this, there won't be enough deals managed under the new configurations to accurately compare forecast against actual results.

---

## Salesforce Service Cloud Implementation: Cases, SLA, Routing & Knowledge
URL: https://hpi.pro/en/insights/service-cloud-implementation
Many service centers implement Service Cloud only to find response times haven't improved. The challenge almost always lies not with the tool itself, but with four critical, unresolved decisions: what constitutes a 'case,' who handles it, when the clock starts ticking, and what happens when the answer already exists. This guide breaks down these four decisions into actionable, verifiable outcomes.

## The Short Answer

Service Cloud doesn't inherently shorten response times. Instead, it enforces the configurations you provide. If you haven't decided what constitutes a Case, who receives it, or when the clock starts ticking, the system will precisely measure an undefined process. The resulting metrics may appear either better or worse than reality, regardless of the actual service provided.

Four decisions determine the outcome: Case Definition, Assignment Model, SLA Clock, and Knowledge Location. The rest of the implementation—screens, channels, automations—are derived from these foundational choices.

## Decision 1: What Constitutes a Case

Many contact centers open a Case for every interaction, believing "that's how we get data." The result is counterproductive: thousands of records closed within a minute inflate volume, artificially improve average resolution time, and obscure the inquiries that genuinely get stuck.

An effective definition distinguishes between three types:

| Interaction Type | Is a Case Opened? | Reason |
| --- | --- | --- |
| Question answered during call | No, recorded as Interaction | No follow-up or commitment needed |
| Request requiring action or waiting | Yes | Follow-up and SLA required |
| Recurring issue/bug | Yes, with reason classification | Trend analysis required |

## Decision 2: Who Receives the Inquiry

A common pitfall is routing solely by department, which creates one large queue where agents "cherry-pick" easy inquiries. Complex inquiries languish at the bottom of the queue until someone escalates them via phone, rendering the entire SLA mechanism a performance rather than effective.

A proper assignment model defines three dimensions: required skill, agent's actual capacity (not just case count, but weight), and time-based escalation rules. Omni-Channel Routing supports all three, but only if genuine skills are defined. Labeling "Skill: Support" for all agents is equivalent to having no definition at all.

A comprehensive explanation of omnichannel assignment is available in [Omnichannel and SLA in Service Cloud](/en/insights/service-cloud-omnichannel-sla).

## Decision 3: When the Clock Runs

This is the decision most organizations skip, and it's the one that determines whether metrics are reliable. Questions that demand written answers:

1.  **When does the clock start?** – Upon inquiry receipt or at the start of the next business hours? Business Hours must be configured for every relevant time zone.
2.  **When does it stop?** – A Case awaiting customer response must pause the timer; otherwise, the contact center is penalized for customer delays.
3.  **What exactly is measured?** – First response time, resolution time, or both with separate targets for each severity level.
4.  **What happens before a breach?** – A Milestone that triggers an alert at 80% of the allocated time is more valuable than a monthly breach report.

Entitlements and Milestones are the mechanisms that implement these four points. Activating them without a pre-defined written decision will generate alerts that are ignored within two weeks.

## Decision 4: Where Knowledge Resides

A Knowledge Base isn't a separate project; it's a prerequisite for reducing workload. The typical failure: articles are written at launch, no one maintains them, and within six months, agents resort to asking questions in internal chat.

What works: A defined lifecycle for each article—Owner, re-evaluation date, and usage metrics. A Case closed without a linked article, and appearing five times in the same quarter, automatically triggers article creation. More in-depth information on this topic is available in [Salesforce Knowledge Management](/en/insights/salesforce-knowledge-management).

## Operational Metrics

| Metric | Definition | Threshold for Review |
| --- | --- | --- |
| First response time | Until first human contact | Exceeds 10% of inquiries |
| First contact resolution | Closed without transfer | Below 60% |
| Reopen rate | Case reopened within 7 days | Above 8% |
| Backlog aging | Open Cases exceeding SLA | Weekly upward trend |
| Knowledge attach rate | Cases with a linked article | Below 30% |

Reopen rate is the most crucial, yet often most neglected, metric: it uncovers premature closures made to meet time targets.

## Recommended Workflow

First wave: Case definition, one or two channels, basic Routing, SLA for one severity level, and ten Knowledge articles for common inquiries. Second wave: additional channels, skills, full Entitlements, Self-Service. Implementing everything at once forces a contact center to contend with process changes, tool changes, and measurement changes in the same week, often leading them to revert to workarounds.

## Summary

Successful Service Cloud implementation is measured by one question: Can the contact center manager, using the system and without a supplementary spreadsheet, show where overdue inquiries are and why? If the four decisions are locked in—the answer exists. If not—you have a new system and the same contact center.

### Questions and answers
**Should every customer interaction be logged as a Case?**
Not necessarily. A quick question resolved during a call that doesn't require follow-up isn't a Case. Over-logging inflates data and skews volume and resolution metrics. The practical rule: Open a Case when follow-up is needed, a time commitment is made, or documentation is required for analysis.

**Queue-based or Omni-Channel Routing?**
Queue-based routing is suitable for smaller contact centers with versatile agents. Omni-Channel is essential when managing parallel channels, diverse agent skill sets, or needing to balance workload dynamically based on real-time capacity.

**Is it mandatory to use Entitlements to manage SLA?**
While you can track SLAs through reports alone, Entitlements and Milestones are crucial for proactive alerts and escalations *before* a breach occurs, rather than just reporting on it retrospectively.

**When is the right time to implement a Customer Portal or Self-Service?**
Only after your Knowledge Base is robust with actual solutions to common inquiries. A portal that directs users to an empty knowledge repository will merely increase inquiries across other channels.

**How many Case types should we define?**
Keep it lean – typically three to five – and utilize a secondary classification field. An overly detailed taxonomy can lead agents to select the first option on the list, diminishing the analytical value.

---

## Sales Cloud vs. Service Cloud: What's the Difference and Which Does Your Business Need?
URL: https://hpi.pro/en/insights/sales-cloud-vs-service-cloud
The decision between Sales Cloud and Service Cloud often presents itself as a product comparison, but it's fundamentally about workflow: Are you managing a progressive sales deal or a time-sensitive service inquiry? This guide dissects both platforms based on core objects, key metrics, and licensing, demonstrating when to leverage both and how to integrate them seamlessly without data duplication.

## The Short Answer

Sales Cloud manages a **progressing deal** – a work unit that lives for weeks or months, is measured by close probability, and succeeds when closed. Service Cloud manages a **resolved inquiry** – a work unit that lives for hours or days, is measured by response and resolution time, and succeeds when closed quickly and without recurrence.

This distinction, rather than a feature list, dictates the choice. If you're managing a Pipeline, use Sales Cloud. If you're managing a queue with an SLA, use Service Cloud. If you're managing a customer who buys and also complains, use both, tied to the same Account.

## Operational Differences

| Dimension | Sales Cloud | Service Cloud |
| --- | --- | --- |
| Core Object | Opportunity | Case |
| Lifecycle | Weeks to Months | Hours to Days |
| Leading Metric | Win rate, Forecast accuracy | First response, FCR, CSAT |
| Assignment Mechanism | Persistent individual ownership | Dynamic routing by availability |
| Workload Source | Number of active deals | Unpredictable channel spikes |
| Knowledge Component | Playbooks and pricing | Built-in Knowledge Base |

The most crucial line is the assignment mechanism. In sales, individual ownership is valuable – customers want a consistent point of contact. In service, individual ownership is a flaw – it creates personal queues that stall when a representative is on vacation.

## When the Choice is Clear

**Sales Cloud only** is suitable for an organization that sells through an ongoing process where post-sale support is minimal or handled by a partner – for example, an equipment supplier selling through resellers who doesn't operate a call center.

**Service Cloud only** is suitable for an organization where all customer interaction involves handling requests – an operational services company, a public body, or an infrastructure provider with existing contracts.

**Both** are required when renewals, upsells, or retention are in play: the moment a service representative needs to know the customer is in a renewal process, and a sales representative needs to know the customer opened three severe cases this month – the separation becomes an obstacle.

## How to Connect Without Duplicating Data

This is where combined implementations often fail. The rule: **Account and Contact form a single shared layer**. There are no separate "sales customers" and "service customers."

From this, three decisions follow:

1.  **Ownership of the customer record** – who updates contact details, address, and organizational structure. Typically service, as they interact with the customer more frequently.
2.  **Mutual visibility** – a service representative sees open opportunities as read-only; a sales representative sees open cases and satisfaction metrics. Both directions are determined by the Sharing model, not by copying fields.
3.  **Cross-domain triggers** – a critical case for a customer undergoing renewal should generate an alert for their account manager. This mechanism is more valuable than any combined dashboard.

In-depth information on permissions and visibility is available in [Salesforce Sharing and Visibility Design](/en/insights/salesforce-sharing-visibility-design).

## Licensing: What You Need to Know Before Comparing Prices

A Service Cloud license is overarching – it includes basic Sales Cloud capabilities, so a user who needs both does not require two licenses. The reverse is not true: a Sales license does not include Case management, Entitlements, or Knowledge.

The practical implication: accurate cost calculation begins by mapping users by what they actually do, not by the department they belong to. A representative who touches a deal twice a year is not a sales user.

## Implementation Order When Both Are Needed

Parallel implementation looks efficient but actually doubles the risk: two processes changing simultaneously, two user groups in training, and an inability to attribute success or failure to a specific source.

The recommended order is to start with the side that has more measurable pain – typically service, because response time and churn are already being measured – and add the other side after two months of stable operation. The shared layer (Account, Contact, permissions) is built in the first wave, even if only one side goes live; otherwise, the second wave will require dismantling.

## Conclusion

The question is not which product is better, but what unit of work the organization manages: a progressing deal or a resolved inquiry. Most mature organizations manage both, and then the real decision is not what to buy, but how to maintain a single customer layer beneath both.

### Questions and answers
**Can I manage service inquiries in Sales Cloud without Service Cloud?**
Technically, yes, using a custom object or Tasks. However, the moment you require SLAs, availability-based routing, Knowledge articles, or multi-channel support, the cost of self-building far outweighs the licensing difference of Service Cloud.

**Do I need two separate Salesforce Orgs?**
Almost always, no. Both Clouds reside within the same Org and share Account and Contact data. Separating into different Orgs is typically considered only for regulatory compliance or completely independent business entities.

**What happens if a user needs features from both Clouds?**
A user with a Service Cloud license also gains basic Sales Cloud functionalities. The inverse is not true – a Sales Cloud license does not include full-fledged Case management capabilities.

**How does the definition of success differ between the two?**
Sales success is measured by deal progression and close rates over weeks; service success is measured by response time, first contact resolution, and satisfaction within hours. This difference in tempo impacts measurement frequency, automation load, and performance planning.

**Where should we start if we need both Sales Cloud and Service Cloud?**
Begin with the side where the pain point is most measurable and impactful. Implementing both simultaneously significantly increases organizational change complexity, making it harder to pinpoint what drives improvement or challenges.

---

## Salesforce Change Management: Your Pre and Post Go-Live Playbook
URL: https://hpi.pro/en/insights/salesforce-change-management-plan
Change management isn't just the week of training before launch. This four-stage playbook — impact mapping, stakeholder engagement, communication, and executive review cycles — provides deliverables, owners, and metrics for each step.

## The Short Answer

Change management is not a communication activity tacked on at the end of a project. It's a parallel workflow that begins with Discovery and concludes months after Go Live. The disparity between successful and failed projects almost always lies here, not in the code.

Four stages, each with a defined deliverable: impact mapping, stakeholder engagement, communication and training, and an ongoing management cycle.

## Stage 1 — Impact Mapping by Role

Before designing a single screen, define for each affected role: what they do today, what will change, what will become easier, what will become harder, and what will be measured differently. The third and fourth lines are critical—projects fail when someone discovers only upon Go Live that they've lost control or gained additional work.

| Role | What Changes | Main Risk | Planned Response |
| --- | --- | --- | --- |
| Sales Rep | System entry instead of personal Excel | Entry burden, loss of control | Concise form, recurring daily value |
| Sales Manager | System-based forecast | Exposure to unflattering numbers | Prior preparation, private dashboard for transition period |
| Back Office | New approval process | Delays during transition period | Pre-practice, exceptions procedure |
| Management | Single source of truth for reporting | Discrepancies with old reports | Parallel comparison for one quarter |

The deliverable is a two-to-four-page document, serving as input for solution design.

## Stage 2 — Stakeholders and Sponsorship

A genuine Sponsor is someone who can change a process, goal, or incentive. A Sponsor who only appears in an introductory message is not a Sponsor. Three minimum commitments worth getting in writing:

- Participation in monthly project reviews and open decision-making.
- An explicit declaration of the single source of truth and discontinuation of parallel reporting by a defined date.
- Support for process changes, even when inconvenient for a specific department.

Alongside the Sponsor, a network of field representatives is built, functioning as a two-way channel—details in [Building a Salesforce Champions Network](/en/insights/salesforce-champions-network).

## Stage 3 — Communication That's Understood Differently Than Usual

Effective communication answers one user question: what does this mean for me? Messages touting "digital transformation" are perceived as noise. Three principles:

1. **Role-Based Segmentation** — One message for the entire organization doesn't work. Tell a representative what changes on their screen, tell a manager what changes in their review.
2. **Acknowledge the Cost** — Explicitly state what will be harder. Denial erodes trust faster than any real drawback.
3. **Regular Cadence** — A short bi-weekly update from Discovery until Hypercare, even when there's no dramatic news.

The training itself is built around work scenarios, not screens; the recommended structure is detailed in [Role-Based Salesforce Training](/en/insights/salesforce-role-based-training).

## Stage 4 — The Management Cycle After Go Live

This is the most omitted and most crucial stage. Change is cemented only when it becomes part of the management routine:

- Weekly team review from a system dashboard, not a file.
- Monthly management report generated solely from the system.
- Open request channel with periodic releases and communication of what was fixed.
- Monthly adoption measurement based on [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

The significant target date is not Go Live but the day parallel reporting stops. As long as a legitimate shadow report exists, the system remains a secondary one.

## Common Risks and Early Warning Signs

| Warning Sign | Meaning | Reaction |
| --- | --- | --- |
| Sponsor skips two consecutive reviews | No business ownership | Escalate issue to management before UAT |
| "Just one more field" requests accumulate | Process not agreed upon | Freeze and re-evaluate the process |
| Training delayed due to schedule pressure | Project will launch unprepared | Postpone Go Live for relevant team only |
| Managers ask for "the old report too" | Lack of data trust | Correct data before expanding Scope |

## Metrics for the Change Program

Four metrics are measured: the percentage of users who completed scenario training, the core action completion rate in the first two weeks, the number of active shadow files, and the average time to close a change request. The first three indicate adoption, the fourth indicates channel trust.

## Summary

A good change management program begins with impact mapping during the planning phase, relies on a Sponsor with genuine authority, communicates by role, and continues as a management cycle months after Go Live. This is the least expensive part of the project and the most impactful on its ROI.

### Questions and answers
**When should change management begin in a Salesforce project?**
It should start during the Discovery phase, alongside requirements gathering. Impact mapping for roles is an input to solution design, not an output. Starting during the testing phase puts you behind by approximately three months.

**How much budget should be allocated to change management?**
A common range is 10-15% of the total project budget for a medium-sized implementation, and more if organizational structure or compensation models are changing. Projects that cut this budget often incur higher costs later on through remediation efforts.

**Who is responsible for change management – HR, PMO, or the CRM team?**
Ultimately, accountability rests with the Business Sponsor. HR or PMO provide methodologies and tools, the CRM team provides content, but decisions regarding process changes and compensation must be made at the business leadership level.

**How do you handle resistance from middle managers?**
Middle managers often resist when a system creates transparency they find threatening or adds to their workload. The solution is to provide immediate managerial value – such as a dashboard that eliminates manual reporting for them.

**What continues beyond hypercare?**
Three key things: a regular executive review cycle driven by system data, an open request channel with periodic releases, and monthly adoption measurement. Without these, the change will likely regress within two quarters.

---

## Role-Based Salesforce Training: Build a Program That Fosters Self-Sufficiency
URL: https://hpi.pro/en/insights/salesforce-role-based-training
Screen-by-screen training is forgotten in a week. Discover a scenario-based training program structure: tailored paths for each role, hands-on practice in a sandbox with real data, a self-sufficiency assessment, and ongoing maintenance for new hires.

## The Short Answer

Training that simply explains where each button is located will be forgotten by the end of the week. Training that actively practices the scenarios users actually encounter—such as "a customer calls and asks for a quote," "a deal is stuck," or "closing a case with a refund"—will stick, because it's linked to the memory of the work itself.

The structure: A distinct path for each role, lasting between two and four hours, based on hands-on practice in a sandbox with familiar data, culminating in a practical independence test.

## Why Generic Training Fails

Uniform training for an entire organization teaches the lowest common denominator—which mostly means navigation. Each role walks away with 20% relevant content and 80% noise, and arrives on day one without knowing how to perform their specific tasks end-to-end. The result is seeking support for every single action, or reverting to old work methods.

Moreover, generic training obscures interface problems. If it takes 40 minutes to explain how to enter an opportunity, the problem isn't with the training but with the screen itself—a topic discussed in [Salesforce UX Simplification](/en/insights/salesforce-ux-simplification).

## Role-Specific Training Paths

| Role | Core Scenarios | Duration | Independence Test |
| --- | --- | --- | --- |
| Sales Rep | Lead to Opportunity, Stage Advancement, Quoting, Activity Logging | 3 hours | Close a full cycle independently |
| Sales Manager | Pipeline Review, Forecasting, Exception Approval, Team Analysis | 3 hours | Conduct a weekly review using the system |
| Service Agent | Case Creation, Classification, Escalation, Closure with Reason Code | 3 hours | Handle three different cases within target time |
| Back Office | Approvals, Data Corrections, Exceptions | 2 hours | Manage daily approval queue |
| Leadership | Dashboard Review, Data Inquiry | 1 hour | Make a decision relying solely on system data |

## An Effective Session Structure

A 20/60/20 split: Twenty percent context—why the change and what it offers; sixty percent hands-on practice with scenarios; twenty percent Q&A and exception handling. A lecture without an open keyboard isn't training.

Practice takes place in a sandbox with data that mirrors participants' reality: familiar customer names, reasonable amounts, real products. Generic dummy data creates a disconnect and makes it difficult to transition to actual work.

## The Independence Test

A training program must have a measurable completion criterion. This criterion isn't attendance or a knowledge quiz—it's performance: The participant independently completes their core scenario end-to-end, within a reasonable timeframe, without asking for help.

Anyone who doesn't pass receives supplemental quick practice, not a full repeat of the training. Repeated failure by many at the same stage indicates a process or interface issue, which should be addressed before go-live.

## Support Materials: Concise and Task-Oriented

After training, what's truly needed is a one-page document per role and a video library of one-to-three-minute clips per task. Two rules: search by question ("How do I move a deal to the next stage?") rather than by module, and assign a clear owner for updating the material with any system changes.

A 60-page user manual is written once, becomes outdated within two months, and goes unread. Don't invest in it.

## Support in the First Weeks

In the two weeks following go-live, on-site presence of field representatives who can provide immediate assistance is crucial. This network—Champions—is the operational arm of the training, and its development is detailed in [Salesforce Champions Network](/en/insights/salesforce-champions-network). The entire training is a component within a broader plan: [Salesforce Change Management Plan](/en/insights/salesforce-change-management-plan).

## Onboarders After Go-Live

Within a year, a significant portion of users will not have attended the original training. Without a consistent onboarding path, adoption quietly erodes. The onboarding path includes: access to the role-specific training path within two weeks of joining, mentorship from a team Champion, and the independence test itself. This is the most cost-effective action for sustained adoption.

## Measurement

Evaluate three metrics: the pass rate on the independence test, the volume of support inquiries in the first month by topic, and the completion rate of core tasks in the first two weeks, according to [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics). A concentration of inquiries on a single topic almost always indicates a necessary system correction, not a training issue.

## Summary

Build a path for each role centered around work scenarios, practice in a sandbox with familiar data, conclude with a practical independence test, and maintain an onboarding path for new hires. Good training doesn't teach a system—it teaches how to do the work within it.

### Questions and answers
**How many training hours does an end-user need?**
Between two and four hours for core scenarios, delivered in two short sessions rather than one long one. Managers need an additional hour on reports and overview. More than that leads to forgetting, not knowledge retention.

**Is recorded video or live training better?**
A hybrid approach is best. Live training for practicing core scenarios allows for questions, supplemented by short 1-3 minute videos as a task-based reference library. Almost no one watches a 40-minute long video.

**When should training be conducted in relation to Go-Live?**
One week to ten days prior. Training a month in advance is forgotten; training the day before clashes with launch pressure. New hires after Go-Live should complete the same path within two weeks of starting their role.

**How do you train when the system is still changing?**
Freeze core processes two weeks before training and document late changes as a short delta list. Training on a system that's still in flux immediately creates a lack of trust.

**What do you do with users who missed training?**
Block their access until they complete a short essential path, with management backing. A user who enters the system without training generates inaccurate data, which everyone ultimately pays for.

---

## Salesforce Adoption Metrics: Why Logins Aren't Enough
URL: https://hpi.pro/en/insights/salesforce-adoption-metrics
A login is a presence metric, not a value metric. This practical guide helps you build a Salesforce adoption measurement framework that tracks core actions, data quality, and business outcomes — including baselines, role-based segmentation, and an action plan for every insight.

## The Short Answer

A login proves someone entered the system. It doesn’t prove work was done within it, that entered data is reliable, or that a manager can make decisions based on it. An organization reporting 92% logins while simultaneously managing forecasts in Excel hasn’t adopted Salesforce; they’ve merely opened it.

A useful adoption metric answers one question: **Is the business process running end-to-end within the system, at a quality level that allows reliance on it?** From this, four layers of measurement are derived: core actions, data quality, process speed, and business outcome.

## Three Levels of Adoption

| Level | What’s Measured | Example | What It Means |
|---|---|---|---|
| Presence | Login, time spent | 92% logged in this week | Almost nothing |
| Active Use | Core actions by role | 78% of opportunities updated within 7 days | The process is running |
| Value | Business outcome + quality | Forecast variance dropped from 31% to 12% | Adoption paid off |

Most organizations get stuck at the first level because it's the only one available without effort. The next two levels require a preemptive decision: what constitutes a "core action" for each role.

## How to Define a Core Action

A core action is the action without which the process breaks. Not the most common action—the most critical one. For a sales rep, this is typically updating stage and close date; for a sales manager, it's a weekly Pipeline review within Salesforce; for a service agent, it's closing a Case with the correct reason code.

The practical rule: If the action isn't performed, someone downstream is working with incorrect information. If no one is negatively impacted by its absence, it's not a core action, and sometimes shouldn't even be a required field.

For each role, define one to two core actions, explicitly document them in the job description, and measure the percentage of users who performed them within the relevant process timeframe.

## Data Quality Layer

A poorly executed action is sometimes worse than an unexecuted one, as it generates false confidence. Therefore, every quantitative metric needs a qualitative counterpart:

*   Percentage of opportunities with a past close date - Pipeline decay metric.
*   Percentage of Cases closed with a generic "Other" reason code - Broken categorization metric.
*   Percentage of customers without an active contact person - Missing foundational data metric.
*   Percentage of manually created duplicate records - Entry process failure metric.

These four metrics will reveal within a week whether the system is in real or merely ceremonial use. Further details on root cause resolution are available in [Improving Salesforce User Adoption](/en/insights/recover-salesforce-user-adoption).

## Segmentation: The Average Lies

An organizational average of 70% adoption can hide one team at 95% and another at 20%. All measurements must be segmented by at least three criteria:

1.  **Role** – Agent, Manager, Back Office. Each has different expectations.
2.  **Team or Direct Manager** – The biggest difference in adoption is almost always the direct manager, not the training.
3.  **Tenure in the system** – Users who joined after the Go Live did not receive the same training, and their data indicates the onboarding process.

When the gap between the leading team and the lagging team is greater than two-fold, the problem is managerial, not systemic, and the correct investment is in the management layer, not in further development.

## Baseline: The Error You Can't Fix After the Fact

A metric without a reference point is a meaningless number. The Baseline is measured *before* the change – even if manually measured, even if estimated. Ask: How long does it currently take to close a Case? How many opportunities are updated on time? What was the forecast variance for the last three quarters?

If the Baseline isn't measured before launch, it can partially be reconstructed from historical data, but behavioral metrics cannot be recovered. This is why adoption measurement is a planning phase decision, not a Go Live phase decision.

## From Finding to Action

The following table maps common findings to the correct action. The rationale: almost no adoption finding is resolved by additional training.

| Finding | Probable Root Cause | Recommended Action |
|---|---|---|
| High logins, low core actions | System is not part of the daily workflow | Integrate into process: alerts, Path, work lists |
| Actions performed but weeks late | No management cycle relies on the data | Weekly Pipeline review from a Dashboard |
| Low quality in a specific field | Field is irrelevant or unclear | Reduce, change to Picklist, or remove |
| A single team is lagging | Direct manager is not a user | Work with the manager, not the team |
| All fields filled but management doesn't trust | Mismatch between metric and business question | Redefine the outcome metric |

## What It Looks Like in a Monthly Report

A good adoption report fits on one page: four metrics with a three-month trend, segmentation by team, three findings, and three actions with an Owner and date. Without actions, it's a status report; with actions, it’s a management tool.

The link between measurement and organizational work plan is detailed in [Salesforce Change Management Plan](/en/insights/salesforce-change-management-plan), and the training planning derived from findings is found in [Salesforce Role-Based Training](/en/insights/salesforce-role-based-training).

## Summary

Adoption metrics are not a report card for users; they are a fault detection system for the process. If measurement does not lead to changes in the process, interface, or management layer, it only creates work. Start with four metrics, segment by team, establish a Baseline, and link each finding to an action with an owner.

### Questions and answers
**How many Salesforce adoption metrics should we track?**
Between four and six. Aim for one core action metric per key role, one data quality metric, one process speed metric, and one business outcome metric. More than that often leads to dashboards nobody uses.

**What if data shows high adoption, but executives are still dissatisfied?**
This almost always indicates you're measuring activity, not impact. Verify if the actions being measured truly move the business needle—for example, does updating an opportunity stage improve forecast accuracy, or just fill a field?

**Can we measure Salesforce adoption without a dedicated analytics tool?**
Yes. Standard Salesforce Reports and Dashboards, combined with Field History Tracking, are sufficient for most organizations. An external tool is primarily needed for screen-level analysis and click-path tracking at the user level.

**When should we first measure adoption after a Go-Live?**
Two weeks after the Hypercare period concludes, not before. The initial weeks are often skewed by intensive support, data corrections, and initial user enthusiasm.

**How do we prevent metrics from being 'gamed' by users?**
Pair every quantitative metric with a qualitative one. If you're measuring the number of Activities, also track the percentage of Activities with significant content or a link to an opportunity. A single, isolated metric will always invite artificial inflation.

---

## 8 Undeniable Signs Your Salesforce Org Needs an Upgrade
URL: https://hpi.pro/en/insights/salesforce-system-upgrade-signs
A CRM system rarely breaks down all at once. Instead, it erodes over time, and daily users often become blind to its decline. These eight measurable signs don't require an expensive survey or consultant to identify, and each points to a different root cause: process, data, architecture, or governance.

## The Short Answer

A system needs an upgrade when the effort spent working around it exceeds the effort spent working within it. The eight signs below are different expressions of this same phenomenon, but each points to a different root cause—making accurate identification more crucial than a simple headcount.

## The Eight Signs

| # | Sign | What It Reveals |
| --- | --- | --- |
| 1 | Parallel spreadsheets for managing forecasts or queues | The system isn't the single source of truth |
| 2 | Reports displaying conflicting numbers | Unharmonized metric definitions or data duplication |
| 3 | Every change request takes weeks | Automation debt, no proper testing environment |
| 4 | Screens with dozens of fields nobody fills out | Accumulation of requirements without cleanup |
| 5 | Noticeably slow record loading | Duplicate Triggers, cascaded Flows, inefficient queries |
| 6 | Daily recurring manual operations | A process that was documented, not implemented |
| 7 | Permissions granted "to make it work" | A visibility model that has lost its logic |
| 8 | Knowledge held by only one person | Lack of documentation and governance |

## How to Read the Picture

The signs fall into four families, which determine the type of work required:

**Process (1, 6)** - The system is built around a process that isn't the actual process. The fix is re-mapping, not development.

**Data (2)** - The problem lies in definitions and quality, not in the reporting tool. Expand on this in [Salesforce Data Quality Metrics](/en/insights/salesforce-data-quality-metrics).

**Architecture (3, 5)** - Accumulated debt in automations and code. Expand on this in [Salesforce Performance Optimization](/en/insights/salesforce-performance-optimization).

**Governance (4, 7, 8)** - There's nobody deciding what gets in, who sees what, and who documents it. This is the family where, if left unaddressed, other fixes will unravel.

## The Strongest Indicator

Among the eight, a parallel spreadsheet used by a senior manager for decision-making is the most unambiguous sign. It's not a complaint; it's a quiet declaration by the organization that the system is insufficient. As long as it exists, any improvements to reports are just working on a display that nobody relies on.

## What to Do Before Fixing

The temptation is to start with the loudest sign. The effective order is different: two weeks of measurement on the three strongest signs to establish a baseline. Without it, even a successful fix can't prove itself, and funding for the next phase won't be approved.

After measurement comes the decision between a targeted fix and structural work, detailed in [Salesforce Rebuild vs. Refactor](/en/insights/salesforce-rebuild-vs-refactor).

## Summary

The signs are not a list of complaints but a diagnostic tool: each points to a different root cause family, and treating a symptom from the wrong family wastes an entire cycle. Three active signs warrant a structured review; a parallel spreadsheet in leadership alone warrants it.

### Questions and answers
**How many of these signs warrant a Salesforce health check?**
Three out of the eight, or one severe issue – for example, widely conflicting executive reports. A single, minor sign is usually an isolated incident, not a systemic problem.

**Do multiple parallel spreadsheets always indicate a system problem?**
Almost always, but not necessarily a technical one. Spreadsheets emerge when the system doesn't support a real business process or is too slow – two distinct reasons with different solutions.

**What's the difference between an upgrade and ongoing maintenance?**
Maintenance addresses bugs and specific, ad-hoc requests. An upgrade fundamentally changes the structure – data model, automations, or permissions – to eliminate the root cause generating those requests.

**Can these signs be identified without direct system access?**
Yes. Most are externally observable: manual meeting duration, number of files sent via email, or the time it takes to get an answer to a simple reporting question.

**What should we do after identifying these signs?**
Measure before you fix. Two weeks of data collection on the three most impactful signs provides a baseline. Without it, you can't truly prove improvement later on.

---

## Salesforce Sandbox & DevOps Strategy for Enterprises
URL: https://hpi.pro/en/insights/salesforce-sandbox-devops-strategy
The journey from development to production dictates your confidence in a successful release. This guide details essential Sandbox types for each stage, how to build a source-driven pipeline with Git and CI, and best practices for managing manual configurations in production.

## The Short Answer

A well-architected environment strategy answers three questions: where each type of work is performed, how changes move forward, and how to roll back when something breaks. The structure that works for most organizations consists of a Developer org for each developer, a shared integration environment, a UAT environment with representative data, and Production — with Git as the single source of truth and automated deployments at least up to UAT.

## Environment Map

| Environment | Type | What Happens Here | Data |
| --- | --- | --- | --- |
| Personal Dev | Developer | Building, experimenting, unit testing | Metadata only |
| Integration | Developer Pro | Merging all team's work, CI | Small synthesized sample |
| UAT | Partial or Full | Business acceptance, training, edge cases | Masked production data |
| Staging / Full | Full | Release dress rehearsal, volume testing | Masked full copy |
| Production | — | Ongoing operations | Real |

A Sandbox for hotfixes is recommended for organizations whose release cycles exceed two weeks; otherwise, any urgent fix forces the deployment of immature work.

## From Change Sets to Source-Driven

The transition occurs in three phases. First, export existing metadata to a Repo and establish a simple branch structure and strategy — a main branch, a release branch, and short-lived feature branches. Next, connect CI that runs a Validation Deploy against the integration environment, Apex tests, and static analysis for every Pull Request. In the third phase, automated deployment to UAT is implemented, while deployment to Production remains a manually approved operation with a defined release window.

What thwarts this transition is not the tool but the scope: attempting to incorporate the entire org into the Repo at once creates thousands of files that no one can review. It's better to start with a metadata subset for a single business domain and expand incrementally.

## What Doesn't Go into the Repo

Some aspects of the system are not deployable metadata: environment-dependent configuration records in Custom Settings and Custom Metadata, Named Credential values, frequently changing Assignment Rules, and Knowledge content. Each of these categories should have a brief document defining who updates it, where, and how it's synchronized between environments. The absence of this definition is the most common reason for issues that only appear in Production.

The relationship between release velocity and methodology is detailed in [Agile vs. Hybrid Waterfall](/en/insights/salesforce-agile-waterfall-hybrid) and the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## Environment Refresh and Maintenance

A Sandbox that hasn't been refreshed in nine months no longer represents Production, and any testing performed there provides false confidence. The simple rule: a UAT environment is refreshed before every significant Release, and development environments are refreshed at the end of each sprint. It's important to plan ahead for what is lost during a refresh — test data, users, configurations — and maintain a Post-Refresh script that restores them within an hour, not three days.

## Common Risks and Preventive Actions

The first risk is Drift: discrepancies that silently accumulate between Production and the Repo. Weekly automated metadata comparisons with alerts are the only effective defense.

The second risk is Apex tests written solely to meet coverage thresholds. 75% coverage without true Assertions is not a safety net; it provides false assurance precisely when real confidence is needed. The third risk is a human bottleneck: a single individual authorized to deploy. At least two individuals are necessary, with documented permissions.

## How to Measure Success

Four metrics: release frequency, time from merge to Production, failed deployment rate, and number of hotfixes in the month following each Release. True improvement looks like this: frequency increases, time decreases, and both failure rates and hotfixes decrease concurrently. An increase in frequency alongside an increase in hotfixes indicates that the pipeline is faster but testing is insufficient.

### Questions and answers
**How many Sandboxes do we really need?**
For a mid-sized organization, a practical minimum includes a Developer Sandbox for each individual developer, one Developer Pro for integration testing, and a Full or Partial Sandbox for UAT and load testing. Smaller organizations might get by with two; those with multiple concurrent teams will also need a dedicated Sandbox for hotfixes.

**Is it mandatory to switch to Git and automated deployment?**
Not on day one, but certainly before more than two people are touching your Salesforce metadata. Until then, Change Sets might suffice. Beyond that, without a single source of truth in code, it's impossible to track who changed what, and you can't confidently roll back to a previous state.

**What should we do if someone manually changes something in Production?**
Identify changes through weekly metadata comparisons. Revert the change to the main branch as a documented commit. If the change was undesired, undo it. What's unacceptable is for the change to exist in Production but not in your repository, as the next deployment will then inadvertently overwrite it.

**Does a Full Sandbox contain live data, and what about compliance?**
Yes, it does. Therefore, robust data masking is required before granting broad access. In environments with personal identifiable information (PII), masking or using a Partial Sandbox with representative data sampling are the correct defaults, not a Full Sandbox with a live copy.

**How long does it take to set up a basic DevOps pipeline?**
Typically four to eight weeks: two weeks for repository structure and branching strategy, two weeks for CI and automated testing, and the remainder for team adoption. The slowest part is always changing habits, not implementing tools.

---

## Salesforce Hypercare Post Go-Live: Stabilize with Confidence, Not Dependency
URL: https://hpi.pro/en/insights/salesforce-hypercare-plan
Hypercare isn't a project extension, but a meticulously planned bridge to Business As Usual (BAU). We cover stabilizing your system with: expert team composition, temporary SLAs, daily triage, measurable exit criteria, and seamless ownership transfer to your internal team.

## The Short Answer

The day after Go-Live isn't the end of a project—it's when the true nature of what was built is revealed. Hypercare is a planned period during which the team that developed the system remains available, rapidly addressing gaps while simultaneously transferring ownership to the maintenance team.

Two common, opposing mistakes are skipping this period and leaving users unsupported, or extending it indefinitely, creating permanent dependence on the vendor. Both are avoided by establishing predefined exit criteria.

## How This Period Differs

| Aspect | Hypercare | BAU (Business As Usual) |
| --- | --- | --- |
| Contact Channel | Direct to project team + on-site presence | Standard support queue |
| Response Time for Blocking Issue | Up to one hour | Per ongoing SLA |
| Patch Release Frequency | Daily to bi-daily | Scheduled cycle |
| Decision Authority | Daily accessible process owner | Change advisory board |
| Focus | Stabilization and remediation | Improvement and development |

## Daily Triage is Core

A 20-minute meeting every morning, at a fixed time, addressing three questions: What was opened yesterday? What is currently blocking work? What is being released today? Every request is classified into four categories:

1. **Blocking Issue** — A core business process cannot be performed. Immediate action required.
2. **Data Gap** — Migration or integration returned incorrect information. High priority because it erodes trust.
3. **Training Gap** — The system works as intended, but the user was unaware. Immediate answer and a note to update support materials.
4. **Enhancement Request** — To the backlog, not to be implemented during this period.

This classification is the primary tool for scope control: without it, every request seems urgent, and the stabilization period turns into another development wave.

## Team Composition and On-Site Presence

During the first week, close physical or virtual presence is required in key units. Project personnel sit alongside users, observing failures in real-time and rectifying them the same day. The value of direct observation is far greater than a written report—most critical blockers are never even reported.

Field representatives who accompany the team are part of the Champions Network and therefore receive early training and direct access. Details are in [Salesforce Champions Network](/en/insights/salesforce-champions-network).

## Exit Criteria

Exiting Hypercare is a measurable decision. A common set:

- Zero open blocking issues for five consecutive business days.
- A 60% or greater decrease in daily request volume compared to the peak of the first week.
- Core action completion rate per role above the defined target.
- The three key data quality metrics within the agreed-upon range.
- The internal support team independently handled 80% of requests in the last week.

The last criterion differentiates a true ownership transfer from an arbitrary abandonment. Measurement relies on the same framework described in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## Orderly Ownership Transfer

The transfer begins in the first week, not on the last day. A simple mechanism: from the second week, the internal support team handles requests first, with the project team providing back-end support. Each resolved request is documented in an internal knowledge base in three lines—symptom, cause, solution.

Transfer deliverables: an updated architecture document, a list of integrations with known failure points, periodic runtime procedures, a list of technical debt incurred under pressure, and operational access and permissions.

## Dependence on Launch Method

In a Big Bang launch, the Hypercare period is intense and relatively short, with a large team. In a phased rollout, the period recurs with each wave but on a smaller scale, and lessons are learned from wave to wave. This implication is one of the considerations when choosing a strategy—see [Salesforce Big Bang vs. Phased Rollout](/en/insights/salesforce-big-bang-vs-phased-rollout).

## Weekly Metrics

Daily request volume by category, median resolution time for a blocking issue, percentage of requests handled by the internal team, and the number of technical debt items opened. The first three measure stabilization; the last prevents the period from leaving behind landmines.

## Summary

Plan Hypercare as a phase with a budget, team, daily triage, and numeric exit criteria. Classify every request, do not initiate enhancements during this period, and gradually transfer ownership from the second week. A stable system is not one without issues, but one the organization knows how to fix itself.

### Questions and answers
**How long should the Hypercare period last?**
Typically, two to four weeks for a medium-scale implementation, and six to eight weeks for multi-site rollouts or those with significant data migration. The duration is primarily determined by meeting predefined exit criteria, not just a fixed date.

**What's the difference between Hypercare and ongoing support?**
During Hypercare, the original implementation team is directly accessible, response times are extremely rapid, and critical fixes are deployed almost immediately. For BAU, requests follow standard support queues with scheduled release cycles.

**Who should be on the Hypercare team?**
Key members include a Developer or Admin familiar with the implementation, a Business Process Owner empowered for content decisions, a Data Migration specialist for initial weeks, and a coordinator to manage daily triage.

**How do we prevent Hypercare from lasting indefinitely?**
Establish clear, measurable exit criteria beforehand, communicate them widely, and track progress weekly. Additionally, gradually channel requests to the regular support queue, beginning as early as the second week.

**What about enhancement requests during Hypercare?**
Log them in the backlog for future consideration, but do not implement them during Hypercare. This period is strictly for addressing bugs and critical blockers; developing enhancements at this stage can undermine system stability.

---

## Salesforce User Stories & Backlog: A Guide for Process Owners
URL: https://hpi.pro/en/insights/salesforce-user-stories-backlog
Salesforce project backlogs often falter for the same reasons: user stories that describe UI screens instead of business outcomes, and acceptance criteria written after development. This guide introduces a testable story structure, a Vertical Slice breakdown method, and prioritization techniques that hold up even under pressure.

## The Short Answer

A well-crafted Salesforce story describes **who, what they're trying to achieve, and what will be true after the action** — not which field appears on which screen. The simple test: If acceptance criteria can be written without knowing whether the implementation will be Flow, Validation Rule, or Apex, the story is correctly formulated.

The common pitfall is a story that already contains the solution. The moment it reads "Add a Picklist field to the Opportunity screen," the discussion about the process is over before it began.

## A Structure That Works

| Component | Role | Quality Test |
| --- | --- | --- |
| Context | Who is the user and when are they here | Real role, not "user" |
| Intent | What they are trying to achieve | Formulated in business language |
| Acceptance Criteria | What is being tested | Can be run as a scenario with test data |
| Edge Cases | What intentionally fails | At least one negative |
| Out of Scope | What is explicitly excluded | Prevents arguments during acceptance |

The last point saves most disputes. An explicit statement that what is not included is indeed not included is worth more than three paragraphs of description.

## Breakdown: Vertical Slice, Not Layers

The temptation in a CRM project is to break it down by technical components – data model first, then automations, finally reports. The result is that there's nothing to demonstrate until the end, and no one knows if the process works.

The correct breakdown is vertical: one complete, end-to-end scenario for one user profile. A single opportunity that is opened, progressed, closed, and appears in a report is worth more than ten defined objects without a process. Later, profiles and scenarios are added around that same skeleton.

## Prioritizing When Everything is Urgent

Three criteria are sufficient, in this order:

1.  **Blocks Go-Live?** – Without it, the process is incomplete. There's no room for negotiation.
2.  **How many users per day?** – Frequency trumps intensity of complaint. An item affecting 80 daily agents precedes a request from one manager.
3.  **What is the cost of deferment?** – Does the cost of implementation increase if we do it after launch? A data model change yes, a report change no.

Anything that doesn't pass these three goes into the Parking Lot. This separation prevents the backlog from becoming an archive of wishes. In-depth information on managing scope changes can be found in [Scope Creep and Change Control](/en/insights/salesforce-scope-creep-change-control).

## Requirements Debt: The Silent Failure

Requirements debt arises when a story is closed without deciding what happens in an edge case – it's left as "we'll deal with it later." After launch, these edge cases become the majority of support calls.

The simple discipline: an item is not closed without a documented decision for every open question recorded in it, even if the decision is "intentionally not addressed." Documenting the waiver is better than a lack of documentation.

## Connection to Testing

Well-written acceptance criteria are essentially the UAT scripts. When written after development, UAT becomes a demonstration of what was built instead of a test of what was required. The sequence is detailed in the [UAT Guide](/en/insights/salesforce-uat-guide).

## Summary

A quality backlog is not long but clear: each item states who it's for, what will be measured as success, and what is explicitly not included. These three questions, asked before building rather than after, determine almost all post-project acceptance quality.

### Questions and answers
**How detailed should a user story be before development begins?**
It needs to be detailed enough for a developer to understand what to build and for a tester to know what to test and when it should fail. If acceptance criteria cannot be executed as scenarios, the story isn't ready – regardless of its length.

**Who is responsible for writing acceptance criteria?**
The process owner defines what constitutes success, while the QA or solution architect adds edge cases and specific conditions. Criteria written solely by developers often describe what was built, not necessarily what was truly required.

**What do you do with a requirement that is essentially an open-ended question?**
That's not a user story; it's a Spike – a time-boxed research task yielding a documented decision. Mixing research and development in the same item obscures the true risk and effort involved in estimation.

**Are Story Points necessary for Salesforce projects?**
Relative estimation primarily helps reveal disagreements about scope. The value isn't in the precise number itself, but in the crucial conversations sparked when estimates diverge significantly.

**How can you prevent the backlog from ballooning to thousands of items?**
Limit its depth: any item not slated for review within the next quarter should be moved to a separate 'Parking Lot.' A backlog that no one reads to the end ceases to be a prioritization tool and becomes an archived wish list.

---

## Conquering Salesforce Scope Creep: Navigate Change Without Project Paralysis
URL: https://hpi.pro/en/insights/salesforce-scope-creep-change-control
Scope creep isn't just too many requests; it's the absence of a system to price them in real-time. This guide details a frozen baseline, a streamlined Change Request form, a weekly Change Advisory Board, and pre-allocated change budgets—empowering you to say 'yes' without sacrificing deadlines.

## The Short Answer

Scope creep occurs when there is a perceived gap between what was promised and what was actually built. Three mechanisms resolve this: a documented baseline visible to all, a half-page change request form including an effort estimate, and a trade-off rule stating that any addition either displaces something of similar size or consumes a pre-allocated change budget. Without these, every "small request" vanishes into the sprint, only to reappear at the deadline.

## Why This Happens Specifically in Salesforce

Salesforce is flexible enough that almost any request appears inexpensive. Adding a field takes two minutes, making it difficult to explain to a stakeholder why it shouldn't be done. However, that field entails validation rules, permissions, a column in a report, mapping in migration, a line in training, and UAT testing. The true cost is five to ten times greater than the build time, and this is precisely the discrepancy no one sees at the time of the request.

## Four-Component Control Framework

| Component | What it includes | Who is responsible | Deliverable |
| --- | --- | --- | --- |
| Frozen Baseline | List of capabilities, scenarios, and explicit Out of Scope items | Product Owner | Signed document at the end of Discovery |
| Change Request | Description, business driver, effort estimate, impact on date | Requester + Tech Lead | Half-page form |
| Change Board | Weekly 30-minute discussion of all open requests | Sponsor, PO, Tech Lead | Decision: Approved / Rejected / Deferred to next wave |
| Change Budget | 10%–20% of the project scope, allocated at project start | Sponsor | Weekly balance tracking |

## The Power of Explicit Out of Scope

The most crucial section in the Baseline document isn't what's included, but what's explicitly *not* included. Statements like "Integration to the payroll system is not included in the first wave" or "Migration of activity before 2022 is not included" save weeks of debate. The rule: anything a stakeholder might mistakenly assume is included must appear in the exclusions list by its full name.

## How to Say "Yes" Without Paying For It

Blanket rejections lead to projects that finish on time but serve no one. The effective approach is to accept every request into a backlog, price it transparently, and let the stakeholder choose: implement now at the expense of another item, wait for the next wave, or consume from the change budget. When the choice is transparent, the discussion shifts from emotional to economic—and in practice, about a third of requests drop off once the cost is revealed.

Further details on defining the Baseline are available in [Defining Your MVP for Salesforce](https://example.com/insights/salesforce-mvp-scope) and [The Ultimate CRM Discovery Guide](https://example.com/insights/crm-discovery-guide).

## Common Risks and Preventive Actions

The main risk is overly heavy control. A process requiring three forms and two weeks of waiting causes teams to circumvent it—and changes continue, just without documentation. A half-page form and a weekly discussion are the practical ceiling.

A second risk is technical creep: architectural decisions made within a sprint that expand the scope without anyone calling it a change. Therefore, any significant architectural change must also go through the same change board. A third risk is an absent Sponsor: when there's no one with authority to say "no," every request gets a "we'll look into it"—which is equivalent to a "yes."

## How to Measure Success

Track four numbers in a weekly report: number of requests opened, percentage approved, cumulative change in project scope versus the Baseline, and remaining change budget. A healthy project shows a cumulative change of up to 15% and a positive budget balance during the UAT phase. Cumulative change above 30% indicates that the Discovery phase was too superficial, not that the team is undisciplined.

### Questions and answers
**What's the difference between legitimate learning and scope creep?**
Legitimate learning refines the solution within the same business outcome. Scope creep adds a new outcome without adjusting timelines or budgets. The practical test: if a request stems from discoveries during initial phases or UAT, it's learning. If it arises from a department joining late, it’s an expansion.

**How much change budget should be pre-allocated?**
Allocate between 10% and 20% of the project's overall budget, depending on the level of uncertainty. A project with extensive discovery and well-defined processes might suffice with 10%; one involving multiple business units or a migration from undocumented legacy systems will likely need closer to 20%.

**Who has the authority to approve changes?**
A Product Owner can approve swaps within the existing baseline that don't impact original timelines or costs. A Project Sponsor approves anything that shifts deadlines, budget, or core outcomes. A clear chain of command is your most effective defense against creep.

**What if the vendor says, 'That's not in the proposal'?**
Cross-reference with your Statement of Work (SOW) and discovery documentation. If it's a true scope expansion, price it as a change. If it's a gap due to ambiguous definitions in the proposal, it's shared responsibility. Clearly documented assumptions in the contract prevent this debate upfront.

**Does Agile eliminate the need for change control?**
No. Agile allows for easy backlog reprioritization, but overall budget and deadlines remain fixed. Agile change control then becomes a 'swap rule' — every new item entering the scope must push out a comparable item of similar size and effort.

---

## Agile, Waterfall, or Hybrid for Your Salesforce Project? Choosing the Right Delivery Model
URL: https://hpi.pro/en/insights/salesforce-agile-waterfall-hybrid
The methodology debate in Salesforce projects often boils down to two core questions: how many decisions can be deferred, and how much time do users genuinely have available? This guide dissects the choice into three critical variables and outlines the hybrid model that most organizations ultimately adopt.

## The Short Answer

The choice isn't about two ideologies, but rather two types of decisions. Some decisions incur exponentially higher change costs over time—like data models, permissions, and integrations—and need to be locked down early. Others have low change costs—like screens, fields, reports, and wording—and are best discovered iteratively.

Therefore, the model that works for most Salesforce projects is hybrid, not out of compromise, but due to its inherent structure: **a fixed framework with iterative content.**

## The Three Determining Variables

| Variable | Pushes towards early planning | Pushes towards iterations |
| --- | --- | --- |
| Process Clarity | Structured and documented process | Changing or undefined process |
| User Availability | Low, limited time | High, weekly review possible |
| Regulatory Exposure | Audits, compliance, approvals | Minimal |

The second variable is more crucial than commonly assumed. Agile without user availability isn't Agile; it's a series of sprints where nothing gets reviewed, and all feedback arrives at once during UAT.

## The Hybrid Structure in Practice

The effective approach divides the project into two parts with different paces:

**Framework Phase (4-6 weeks, planning-intensive)** - Data model, permissions and visibility model, integration mapping, migration strategy, and definition of processes for the first wave. Deliverables are documented and approved.

**Delivery Waves (2-week sprints)** - Each wave delivers a complete scenario for a user profile, including testing and feedback. Changes within a wave do not require re-approval as long as they don't impact the framework.

The rule that holds this together: **A change to the framework is a managed decision; a change to the content is ongoing work.** Without this distinction, every small request goes to the steering committee, and every structural change slips under the radar.

## Where Each Model Breaks

**Pure Waterfall** breaks at UAT: The gap between what was written in a document six months ago and what the user expects is discovered too late for a cheap fix.

**Pure Agile** breaks at the data model: After six sprints of local decisions, it's discovered that the structure doesn't support cross-process reporting, and fixing it requires a migration.

**Hybrid** breaks when the framework isn't truly finalized—when it's a "framework" in name only and is reopened in every wave. Then, you end up with the disadvantages of both models.

## What to Measure Along the Way

Three metrics are enough to know if the model is working: the ratio of completed items to reopened items, time from user feedback to fix, and the number of changes that impacted the framework. An increase in the third metric is the earliest sign that the initial planning was superficial. The connection to scope management is detailed in [Scope Creep and Change Control](/en/insights/salesforce-scope-creep-change-control), and timelines in [Salesforce Project Timeline](/en/insights/salesforce-project-timeline).

## Summary

The right question isn't which methodology is more modern, but rather which decisions in this particular project will be expensive to change later. Those who can answer this will almost automatically arrive at the delivery model—and it's almost always hybrid, with a clear boundary between framework and content.

### Questions and answers
**Can true Agile be achieved with a fixed-price, pre-approved budget?**
Yes, provided the contract defines outcomes, not a list of features. A fixed price against an open backlog creates inherent tension where every change becomes a commercial negotiation instead of a professional discussion.

**What elements remain Waterfall even in an Agile project?**
The data model, permissions architecture, and integration planning. These three are too costly to change later, so they are decided early, even when everything else is iterative.

**What's an appropriate sprint length for a Salesforce project?**
Two weeks in most cases. One week isn't enough for configuration, testing, and feedback; three weeks delays feedback until corrections become too expensive.

**What do you do when users aren't available for reviews?**
Shorten the review to 30 minutes and add a documented decision: anything not reviewed within the timeframe is considered approved. Unaddressed unavailability often leads to 'that's not what we asked for' claims later.

**Does regulatory compliance preclude Agile?**
No. It mandates documentation and approvals at defined points, which is compatible with iterations as long as the approval gates are set in advance and not added mid-project.

---

## Salesforce Big Bang vs. Phased Rollout: Which Implementation Strategy is Right for Your Business?
URL: https://hpi.pro/en/insights/salesforce-big-bang-vs-phased-rollout
Choosing your Salesforce implementation strategy hinges on data and process dependencies, not just methodology preference. This guide explores the trade-offs between a one-time 'Big Bang' launch and a phased rollout, including coexistence costs, migration risks, and a decision framework tailored to your organizational type.

## The Short Answer

The debate between Big Bang and phased rollouts is often framed as a question of risk, but it's primarily a question of dependency. If two units share the same record and process, splitting them into different waves creates an expensive and error-prone interim period. If the units are independent, there's no reason to deploy them all at once.

The practical rule: **First, map dependencies, then choose your strategy.**

## The Two Approaches Briefly

A Big Bang launch deploys all units on a single date. The advantage is a quicker completion, a single source of truth from day one, and zero interim period costs. The disadvantage is concentrated risk: any error impacts everyone simultaneously, and recovery is complex.

A phased rollout deploys one unit or process per wave. The advantage is learning from wave to wave, limited risk, and an improving team. The disadvantage is a longer project duration, organizational fatigue, and an extended period with two systems running concurrently.

## Mapping Dependencies — The Deciding Test

| Question | Answer Leading to Big Bang | Answer Leading to Phased Rollout |
| --- | --- | --- |
| Is the same record actively handled by both units? | Yes, routinely | No, with clear ownership |
| Does the process flow between departments? | Yes, end-to-end | Separate processes |
| Does management reporting consolidate them all? | Yes, daily | Unit-level reporting |
| Is bi-directional synchronization feasible at a reasonable cost? | No | Yes |
| Do the units share the same product catalog and pricing? | Yes | No |

Three or more answers in the left column — splitting into waves will cost more than it saves.

## The Cost of Coexistence

This is the section that drives many decisions yet is often forgotten during planning. An interim period includes: bi-directional synchronization between Salesforce and the legacy system, generating consolidated reports from two sources, supporting two environments, double training for users interacting with both, and managing update conflicts.

A realistic estimate ranges from 10% to 25% of the project budget and increases as the period lengthens. If your plan includes a year of coexistence, seriously consider whether shortening the period is worth the additional risk of a broader launch.

## Migration Risks in Each Approach

In a Big Bang, migration is a single, large event within a short timeframe. It requires full mock cutovers and a proven rollback plan. In a phased rollout, migration repeats with each wave, but on a smaller scale—and each time, a decision must be made about what happens to records related to units not yet live.

In both cases, data quality is the decisive factor for launch day. Detailed planning is available in the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## Decision Matrix by Organization Type

| Context | Recommendation | Primary Rationale |
| --- | --- | --- |
| Up to 150 users, uniform process | Big Bang | Coexistence cost outweighs risk |
| Multiple sites or countries | Waves by site | Regulatory and process differences |
| Several departments with a shared process | Shared core, then waves | Avoids bi-directional synchronization |
| Hard deadline for existing contract termination | Big Bang with limited Scope | No time for interim period |
| Organization with no prior Salesforce experience | Small first wave | Build internal capability |
| Complex migration from multiple sources | Waves | Spreads data risk |

## The Hybrid Approach That Works in Practice

Most successful large implementations combine elements: a uniform Core layer—data model, customers, permissions, basic reporting—goes live for the entire organization at once; above that, waves deploy unique processes unit by unit. This avoids bi-directional synchronization on shared data while still allowing for gradual learning.

Choosing the minimum viable scope for the first wave is a decision in itself, detailed in [Defining MVP in Salesforce](/en/insights/salesforce-mvp-scope). In large organizations, the implications are broader and discussed in [Enterprise Salesforce Implementation](/en/insights/enterprise-salesforce-implementation).

## Implications for Stabilization Period

The strategy also determines the structure of Hypercare: Big Bang requires a large team for an intensive, short period; phased rollouts require a smaller team that returns with each wave, accumulating knowledge. In both cases, defined exit criteria are needed, as detailed in [Hypercare After Go Live](/en/insights/salesforce-hypercare-plan).

## Summary

Map dependencies between units before discussing methodology, quantify the coexistence period in numbers, and choose based on context: a small organization with a uniform process will opt for Big Bang, a multi-site organization will go for waves, and most mid-sized organizations will benefit from a shared core with waves on top.

### Questions and answers
**What's the decisive factor in choosing between Big Bang and Phased Rollout?**
The degree of interdependence between your business units. If a single process spans multiple departments, with the same record handled by both, splitting into phases necessitates expensive two-way synchronization, often pushing the decision towards a Big Bang approach.

**What is the true cost of a Coexistence period?**
Coexistence typically adds 10% to 25% to your project budget, encompassing two-way data synchronization, duplicate reporting, supporting two systems, and potential user confusion. This cost is frequently underestimated when planning phased rollouts.

**Should the first phase be the largest team?**
No, quite the opposite. The initial phase should involve a sufficiently representative unit to learn from, yet small enough to recover from any challenges. A unit of 20 to 50 users with a complete end-to-end process is an ideal choice for a pilot phase.

**When is a Big Bang approach the right choice for Salesforce implementation?**
A Big Bang approach is often suitable for organizations with up to approximately 150 users, a uniform process, controlled data migration, and a non-negotiable hard deadline (e.g., legacy system contract expiration). In these scenarios, the costs of a prolonged coexistence period can outweigh the risks of a single, comprehensive launch.

**Can I combine Big Bang and Phased Rollout strategies?**
Yes, and this hybrid approach is increasingly common. Many organizations opt for a unified 'Core' system launch across the entire organization (Big Bang style), followed by phased rollouts for specific modules or unique departmental processes to address their individual needs.

---

## Salesforce ROI: How to Define & Measure True Value
URL: https://hpi.pro/en/insights/salesforce-roi-kpis
Most CRM project ROI calculations are done once, for budget approval, and then forgotten. This guide offers a different approach: four distinct value types, a pre-launch baseline, and attribution rules to prevent falsely crediting all business improvements to your new system.

## The Short Answer

The ROI of a Salesforce project isn't a single number but rather four distinct value streams: operational efficiency, revenue, risk, and system cost. Blending these into one figure creates a claim that's impossible to prove or disprove.

The practical rule: measure a maximum of six metrics, each with a baseline collected before go-live and owned by someone other than the system builder.

## The Four Value Streams

| Stream | Metric Example | When Measured | Certainty Level |
| --- | --- | --- | --- |
| Operational Efficiency | Service request handling time, proposal creation time | First quarter | High |
| Revenue | Win rate, average deal size, sales cycle length | 2-3 sales cycles | Medium |
| Risk & Compliance | Audit findings, permission exposure | Annually | Quantitatively low, impactfully high |
| System Cost | Canceled licenses, removed integrations | Immediately upon shutdown | Very high |

The last stream is often the easiest to prove and the first to be forgotten. Shutting down two auxiliary systems and one integration provides a definitive number on an invoice, requiring no assumptions.

## Baseline: The Point Determining if Measurement is Even Possible

Without prior measurement, any post-launch discussion devolves into a debate about memory. A proper baseline requires three things: a written definition of how the metric is calculated, a data source that remains available after the transition, and a sufficiently long time window to cover seasonality.

A common mistake is measuring the baseline only from the old system. If 40% of the work happens in spreadsheets, the measured baseline will appear better than reality, and the improvement will seem smaller than it actually is. Documented manual estimation is preferable to precise data from an incomplete source.

## The Rule of Attribution

After a successful launch, there's a temptation to attribute every improvement to the system. Three filters curb this:

1.  **Causality Filter** - Is there an explained mechanism connecting a system change to a metric change? If not, it's correlation.
2.  **Control Group Filter** - Does a group that hasn't yet transitioned show the same trend? If so, the cause is external.
3.  **Volume Filter** - Did the metric increase, or did activity increase? Normalizing by volume eliminates most illusions.

Someone willing to declare "This improvement isn't ours" gains trust even when claiming an improvement that is theirs.

## The Cost Side: What's Omitted from Calculation

The project cost isn't just the contract price. The full calculation includes three years of licensing, an annual maintenance and change percentage (typically 15%-25% of build cost), internal employee time in meetings, UAT, and training, and the cost of parallel operations during the transition period.

A calculation that skips the maintenance item shows a quick first-year return and a second-year loss. Details of cost structures are available in [Salesforce Implementation Cost](/en/insights/salesforce-implementation-cost).

## What to Measure in the First Quarter

In the first quarter, there's no measurable business value yet, so leading indicators, not results, are measured: the proportion of processes performed within the system rather than externally, the data quality in fields feeding reports, and the number of change requests indicating a process gap. These three predict whether value will be achieved. Detailed adoption metrics are available in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## Summary

Reliable ROI is built on separating certain value (systems shut down) from estimated value (revenue), on a baseline collected on time, and on a willingness to forgo attribution that doesn't hold up to scrutiny. A modest, watertight model is worth more than a grand promise no one will ever re-examine.

### Questions and answers
**When should the Baseline be measured?**
Measure your baseline before the new system impacts any processes – typically during the discovery phase. A baseline collected post-launch will already be influenced by changed behavior and cannot be used for accurate comparison.

**How do you differentiate between system impact and market impact?**
Employ three strategies: compare with a control group (if applicable), normalize by activity volume, and focus on process metrics (e.g., cycle time, re-touch rate) which are less sensitive to demand fluctuations.

**Is saving agent time considered ROI?**
Only if the freed-up time is reallocated to measurable, productive activities, or if it offsets the need for additional hires. Ten minutes saved per day by an agent who remains in the same role with the same output does not represent a cash flow saving.

**What is a reasonable timeframe for payback?**
For a mid-sized project, process metrics typically shift within one quarter, revenue metrics within two to three sales cycles. Full cash flow payback is usually measured over 18 to 30 months, including ongoing operating costs.

**What cost aspects do most organizations overlook?**
Ongoing licensing fees, post-launch maintenance and modifications, internal employee time for project work and training, and integration costs that require continuous management. Ignoring these creates an ROI that looks good only on paper.

---

## Salesforce Implementation RFP: Structure, Questions, and Must-Have Deliverables
URL: https://hpi.pro/en/insights/salesforce-rfp-guide
An RFP detailing a laundry list of requirements often yields a list of promises. A strong RFP articulates processes, volumes, and open decisions, compelling each vendor to demonstrate their strategic thinking. This guide provides a nine-part document structure, key questions to differentiate providers, and essential deliverables to request in proposals.

## What a Good RFP Should Achieve

The purpose of an RFP isn't to get a price. It's to obtain **comparable proposals** and identify which vendor truly understands the problem. A document detailing a hundred requirements and asking for "supports / doesn't support" checkboxes achieves the opposite: all vendors check "supports," and the decision boils down to price.

Practical difference: Instead of writing "The system will allow opportunity management," describe that the company manages about four hundred deals a month, each deal passes through a pricing approval, and this approval currently happens via email. Vendors will return very different answers—and that's precisely the point.

## The Nine Sections of a Salesforce RFP

**1. Background and Business Objectives.** What the organization does, what the problem is, and what success will look like in a year. One paragraph to one page.

**2. Current State.** Systems in use, number of users, what works today, and what doesn't. If there's an existing Salesforce environment, specify edition, age, and customization level.

**3. In-Scope Core Processes.** Three to seven processes, each in a paragraph: who performs it, what the decision points are, what happens when something deviates.

**4. Volumes and Data.** Number of records for each central entity, monthly creation rate, years of history to retain, and known data quality status. This section has the most impact on pricing accuracy and is most often skipped.

**5. Integrations.** For each system: name, interface type if known, direction, required frequency, and its owner within the organization.

**6. Constraints.** Regulation, information security, storage location, languages, accessibility, immovable timelines.

**7. What is Required from the Bidder.** Proposed approach, wave plan, team composition with names and roles, assumptions, risks, and pricing according to a fixed structure.

**8. Evaluation Method.** Criteria and weights, published in advance. This generates focused proposals and reduces arguments after the award.

**9. Tender Schedule.** Questions due date, answers due date, submission due date, demo date, decision date.

## Data You Must Disclose to Get Real Pricing

| Data Point | Why it's Critical | What Happens Without It |
| --- | --- | --- |
| Number of users by type | Determines licensing, training, and permissions | Proposals with too wide a range |
| Record volume and history | Determines migration effort | Migration priced with rough estimate |
| Number of source systems | Determines complexity and integration | Surprises after signing |
| Level of existing documentation | Determines how much discovery is needed | Vendors assume existing documentation |
| Availability of process owners | Determines decision pace | Unrealistic timeline agreed by both sides |
| Budget or range | Focuses the solution | Proposals that are not comparable |

## Questions that Distinguish Vendors

The following questions elicit very different answers from various vendors, making them useful. A question everyone answers identically isn't worth space in the document.

- What are the three main assumptions your proposal is based on, and what is the impact if one of them is incorrect?
- In what cases would you recommend configuration even if development would work better, and vice versa?
- Describe a project where you exceeded the timeline. What caused it, and what have you changed since?
- Who will be the actual team members, and what percentage of time will each dedicate to this project?
- What do you need from us to succeed, and what will you do if you don't get it?
- How will you transfer the ability to maintain the system without you?

The last question is a good test of the engagement's nature. A vendor who dodges it is planning for dependence.

## What to Demand as a Deliverable Within the Proposal

- **Preliminary architectural diagram** at the block level, including sources of truth.
- **Wave plan** with the content of each wave, not just dates.
- **Detailed pricing in a uniform structure** that you dictate, by phase and by role.
- **Explicit list of assumptions.**
- **Risk map** with mitigation strategies.
- **Example of a real deliverable** from a previous project, anonymized — for example, a decisions document or a test plan.

The last item is perhaps the most distinguishing, as it shows a standard of work rather than a promise.

## Uniform Pricing Structure — The Tool that Prevents Apples-to-Oranges Comparisons

Define the table that every bidder must complete:

| Phase | Senior Hours | Junior Hours | Cost | What is Considered Complete |
| --- | --- | --- | --- | --- |
| Discovery | | | | |
| Configuration and Development for Wave 1 | | | | |
| Integrations | | | | |
| Data Migration | | | | |
| Testing and UAT | | | | |
| Training and Adoption | | | | |
| Post-go-live stabilization | | | | |
| Project Management | | | | |

A vendor who refuses to break down the price according to this structure is not necessarily expensive—but they cannot be compared, and that's a sufficient reason to demand it.

## Illustrative Example: A Medium-Sized Provident Fund

This scenario is hypothetical and illustrative. A financial institution issued an RFP that included eighty functional requirements in a table. The four bidders checked "supports" on almost every line, and the proposals differed only in price and number of hours.

In a second round, the document was changed: instead of the requirements table, it included three fully described processes, actual volume data, and a request to solve one scenario in a demo. The proposals received differed significantly—one proposed a completely different data model, another identified a dependence on regulatory approval that no one had thought of.

The committee did not choose the cheapest proposal and did not regret it. They chose the one that successfully explained why the seventh requirement in the original document was not needed at all.

## Common Mistakes in RFP Writing

- Copying a document from another project without adapting volumes and processes.
- Requesting a client list instead of deliverable examples.
- Evaluation criteria formulated after proposals are received.
- A timeline that doesn't allow time for questions and answers.
- A hidden preference for an existing vendor, which causes others to invest in vain and harms the quality of future proposals.

## What Happens After Submission

A good document is only half the work. The next step is normalizing the proposals and comparing them on the same basis, as detailed in the [Salesforce Proposal Comparison Guide](/en/insights/compare-salesforce-proposals), and then structured scoring according to pre-defined weights, as detailed in the [Vendor Scorecard Guide](/en/insights/salesforce-vendor-scorecard).

The information base for writing the document itself usually comes from a short consulting process, as described in the [Salesforce Consulting Guide](/en/insights/salesforce-consulting-guide), and the criteria for vetting the company are summarized in the [Choose Salesforce Implementation Company Guide](/en/insights/choose-salesforce-implementation-company).

## Next Step

Before you send the document, do one check: give it to someone in the organization not involved in the project and ask them to explain in a sentence what problem you are trying to solve. If they can't, neither will the vendors—and they'll simply return what they're used to selling.

### Questions and answers
**How many vendors should be invited to a Salesforce implementation RFP?**
Three to five. Fewer than three doesn’t provide adequate comparison, while more than five creates an evaluation overload that often leads the committee to prioritize price over substance. If there are more qualified candidates, it's better to conduct a brief qualification round based on a concise questionnaire before sending the full RFP.

**Should a budget be disclosed in the RFP?**
It's best to disclose a range or a cap. Disclosure prevents irrelevant proposals and allows vendors to suggest phased implementations within the given framework. Non-disclosure often leads vendors to price what they guess you'll approve, rather than what's truly needed to solve the problem.

**What if vendors ask questions that expose gaps in the RFP document?**
Publish all questions and answers to all bidders simultaneously, and update the document if necessary. A good question from a vendor is a positive indicator, so it's valuable to document who asked what – this is one of the best measures of their depth of understanding.

**Should a live demo be required as part of the RFP?**
Yes, but not a standard product demo. Ask the bidder to solve a short, real-world scenario from your business and explain their implementation considerations. A standard product demo shows what Salesforce can do, which doesn't differentiate vendors; solving a scenario reveals how the vendor thinks.

**How much time should vendors be given to submit a proposal?**
Three to four weeks for a medium-sized project, including a Q&A round midway. Too short a deadline results in template-based proposals, which is exactly what you’re trying to avoid. If timelines are tight, it’s better to reduce the scope of information required in the proposal rather than shortening the preparation time.

---

## Mastering Salesforce Project Quotes: Beyond the Lowest Price
URL: https://hpi.pro/en/insights/compare-salesforce-proposals
A quote that's 30% cheaper is almost always for a different scope, not a better deal. True comparison starts with normalization: identical scope, warranty period, and identification of hidden components. Here's a six-step normalization method, a map of expenses often missing from quotes, and a three-year total cost of ownership (TCO) comparison model.

## Why Salesforce Proposals Are Almost Never Comparable

When you lay three proposals side by side and see a difference of tens of percentages, the instinct is to assume one of them is inflated. In most cases, the reason is simpler: each proposal prices a different project.

One vendor included three years of history migration, the second assumed one year. One included six weeks of stabilization after go-live, the second delivered and departed. One counted four integrations, the second two, because they assumed a daily report instead of a live interface. Neither of them misled – they simply weren't told otherwise.

Comparison therefore begins with normalization, not a price table.

## A Six-Step Normalization Method

**1. Define a uniform list of components.** Eleven lines are sufficient: discovery, configuration, development, integrations, migration, testing, training, project management, stabilization, documentation, knowledge transfer.

**2. For each proposal, mark what is included, what is partial, and what is missing.** Do not fill in amounts at this stage.

**3. Price the missing elements.** For any component not included in a proposal, use a cost from another proposal as an estimate and add it.

**4. Align assumptions.** Number of users, edition, years of history, number of business units, languages.

**5. Align warranty periods.** A different period is worth money. A two-month difference in stabilization is a real cost component.

**6. Calculate average hourly cost and team mix** at each stage, not in total.

Only after these six steps can you compare numbers. In many cases, the proposal that seemed cheaper moves to second place.

## Components That Disappear from Proposals – and Appear on the Bill

| Component | Why It's Omitted | Relative Order of Magnitude |
| --- | --- | --- |
| Data cleansing before migration | Considered the client's responsibility | Often very significant |
| Second UAT round | Assumes one round | Low but blocks schedule |
| Role-based training | Priced as a single workshop | Medium |
| Increased support in the first weeks | Not defined | Medium to High |
| Organizational ownership of documentation | Considered self-evident | Low, critical later |
| Integration error handling and monitoring | Only includes the "normal path" | Medium |
| Environments and DevOps | Assumes they exist | Low to medium |
| Internal organizational management hours | Not in the proposal at all | High, and always present |

The last line is the one that surprises management. A Salesforce project consumes significant time from process owners and the PMO, and this is a real cost even if it doesn't appear on any invoice.

## From Price Comparison to Three-Year Cost Comparison

A proposal is correctly evaluated over three years, not just for the project duration. A simple calculation structure:

| Component | Year 1 | Year 2 | Year 3 |
| --- | --- | --- | --- |
| Implementation cost | Full | — | — |
| Licensing | By number of users | Includes projected growth | Includes projected growth |
| Maintenance and support | Partial | Full | Full |
| Planned enhancements | — | Estimated scope | Estimated scope |
| Internal management cost | High | Medium | Medium |

The difference between proposals in the first year seems large. Over three years, what usually matters is how easy it will be to change the system without the vendor – meaning, the quality of documentation and handover, which are almost never factored into the decision.

## Red Flags in a Proposal

- Data migration priced at a round figure with no questions about volume or quality.
- No warranty period, or defined as "bug fixing" without defining what a bug is.
- A proposal that only includes development hours and no project management line item.
- Team composition without names, or names that are not contractually committed.
- An unusually low price for the discovery phase, which is sometimes a gateway to a project that will be priced later.
- No explicit assumptions. A proposal without assumptions is an untested proposal.

## Illustrative Example: Renewable Energy Company

This scenario is hypothetical and for illustration. A company received three proposals. The difference between the cheapest and most expensive was about eighty percent. The committee was leaning towards the cheaper option.

After normalization, it became clear: the cheaper proposal included no migration at all, only loading of active records; it assumed two integrations instead of four, believing financial reporting would be done via manual export; and its warranty period was two weeks compared to eight weeks in the expensive proposal.

After adding the missing costs from the other bidders, the gap narrowed to about ten percent. The decision ultimately made was not based on price but on the question of who offered structured knowledge transfer, as the company had no internal team.

## What to Do with the Remaining Gap

After normalization, a real gap usually remains. Translate it into questions, not assumptions:

- Why is your estimate for integration lower than others' – what do you know that they don't?
- What happens if the assumption about data quality is incorrect?
- How many testing rounds did you plan?
- Which of the presented team members will accompany the project from start to finish?

Answers to these questions differentiate between a vendor who priced cheaply because they are efficient and a vendor who priced cheaply because they didn't understand.

## Connecting to the Final Decision

An organized comparison provides only the commercial aspect. The professional aspect is scored separately, according to pre-defined weights, and price is just one of them – details are in the [Guide to Choosing a Salesforce Implementation Company](/en/insights/choose-salesforce-implementation-company). Understanding what constitutes the cost in the first place is detailed in the [Guide to Salesforce Implementation Cost](/en/insights/salesforce-implementation-cost), and choosing the engagement model in the [Project Pricing Models Guide](/en/insights/salesforce-project-pricing-models).

What is agreed upon in the comparison must be accurately worded in the contract, otherwise it does not exist – the relevant clauses are summarized in the [Guide to Salesforce SOW and Contract Clauses](/en/insights/salesforce-sow-contract-clauses).

## Next Step

Build your normalization table before you open the price envelopes. Anyone who builds it after seeing the amounts will – unintentionally – build it to justify the proposal they already favored.

### Questions and answers
**What does a 40% gap between Salesforce quotes usually indicate?**
Almost always, it means the quotes refer to different scopes, not that one vendor is 1.5 times more efficient. Common discrepancies include data migration (whether included), the number of integrations counted, the post-go-live stabilization period, and user training. Before negotiating price, ensure these three elements are defined identically across all proposals.

**How do you compare quotes with varying team compositions?**
Calculate the average hourly rate and examine the senior-to-junior ratio at each project phase. A quote with a low hourly rate but an entirely junior team might require significantly more hours for the same work. What truly matters is who will lead architectural decisions and what percentage of their time is dedicated to your project.

**Should we ask vendors to revise their proposals after comparison?**
Yes, one round of clarifications is standard and beneficial. Send each bidder only the scope discrepancies you've identified in their specific proposal, without revealing other vendors' pricing, and request an updated quote in the same structure. This process typically closes a significant portion of the gap between proposals and reveals who truly understood the project.

**What if the cheapest quote comes from a less experienced vendor?**
Translate that perceived gap into concrete financial terms instead of discussing it as a 'feeling.' A realistic estimate of an additional remediation cycle, potential project delays, and extra internal management hours will generate a quantifiable figure. Often, the commercial gap shrinks considerably after this financial translation.

**Is Salesforce licensing included in the integrator's quote?**
Generally no; Salesforce licenses are purchased separately. It's crucial to ensure all bidders assumed the same Salesforce edition and number of users, as different assumptions impact the scope of work: a feature available in a higher edition might require custom development in a lower one.

---

## Salesforce Project Contracts & SOWs: Safeguarding Your Delivery
URL: https://hpi.pro/en/insights/salesforce-sow-contract-clauses
Most Salesforce project disputes aren't about price – they're about defining 'done.' A robust SOW clarifies acceptance, mutual dependencies, deliverable ownership, and a smooth exit. Here are twelve critical clauses with recommended phrasing and explanations of how each proactively mitigates risks.

## What Truly Breaks Contracted Projects

Almost no conflict in a Salesforce project begins with the question "How much does it cost?" It starts with the question, "Is it done?" The vendor believes the deliverable has been submitted; the organization believes it's unusable. Both sides are correct within their own perception because no one defined beforehand what "completed" actually means.

This leads to one principle that guides all sections in this article: **A good contract doesn't protect your side in a conflict—it prevents the conflict.**

## Twelve Essential Clauses

### 1. Acceptance Definition for Each Deliverable

This is the most critical clause. Every deliverable requires an observable criterion: not "customer management screen," but "a user with profile X can execute scenario Y and achieve result Z, as defined in the approved acceptance criteria."

Recommended phrasing: A defined testing period begins upon delivery, at the end of which the client either approves or details the discrepancies in writing. Silence beyond this period is considered approval—a clause that protects the vendor and instills discipline in the client.

### 2. Change Request Mechanism

Defines who is authorized to request, who evaluates, within what timeframe, and at what rate. The rate must be established at signing, not when the need arises.

### 3. Bidirectional Dependency

Most contracts define what happens when the vendor is delayed but not what happens when the client is delayed. Result: when an organization is late with approval, the vendor absorbs the impact—and then recoups it through change requests.

Balanced phrasing: The timeline is contingent on defined client responsiveness (approval time, process owner availability, data delivery), and an undue delay shifts the milestone with written notice.

### 4. Ownership of Code, Configuration, and Documentation

Separation between specific deliverables and the vendor's generic components, with a perpetual, unlimited use license for generic components that is not contingent on continued engagement.

### 5. Documentation as a Mandatory Deliverable

Documentation not defined as a deliverable with acceptance criteria either won't be written or will be rushed in the final week. Define a minimum: architectural decisions, data model, integration mapping, operational procedures.

### 6. Warranty and Defect Correction

A defined period and a sharp distinction between a defect and a change. A working definition: A discrepancy between actual behavior and approved acceptance criteria is a defect.

### 7. Key Personnel

Names, allocation percentage, advance notice for replacement, and equivalent professional level with client approval.

### 8. Access, Environments, and Information Security

Who gets access to which environments, for how long, what happens to access upon completion, and how real data is handled in non-production environments.

### 9. Compliance with Regulatory and Privacy Requirements

Storage location, personal data handling, audit rights, and security incident reporting. In regulated organizations, this clause requires specific tailoring, not a template.

### 10. Go/No-Go Gates and Exit Points

The right to pause at the end of a defined milestone, with a predetermined payment arrangement. Such a clause reduces risk for both parties, so a good vendor won't object to it.

### 11. Knowledge Transfer

Not "training," but rather: number of hours, to whom, on what, and what the deliverable is. It's preferable for the transfer to be spread throughout the project rather than concentrated at the end.

### 12. Termination and Exit

A list of what is delivered, format, overlap period, and rate for support hours during transfer. This is the clause no one wants to discuss at signing, which is precisely why it's worth insisting on it then.

## Risk Map: What Each Clause Prevents

| Clause                 | Failure It Prevents                  | Cost of Absence                   |
|------------------------|--------------------------------------|-----------------------------------|
| Acceptance Definition  | "Finished" debate                    | Payment delays and go-live delays |
| Change Requests        | Pricing under duress                 | Uncontrolled cost overruns        |
| Bidirectional Dependency | Mutual blame for delays              | Untransparent timeline shifts     |
| Ownership & Documentation | Vendor dependency                    | High cost in case of vendor change |
| Key Personnel          | Quiet team replacements              | Loss of relationship and knowledge |
| Warranty               | Defect vs. change disputes           | Double payment for fixes          |
| Exit                   | Negotiation from a weak position     | Unforeseen transfer costs         |

## Phrasing to Avoid

*   "The vendor will perform the work with acceptable professionalism" — unenforceable without criteria.
*   "The parties will agree later on..." — every such clause is a future conflict waiting to happen.
*   "Subject to full client cooperation" — without defining what that means, it's a unilateral defense.
*   "The deliverable will be submitted at project completion" — without defining what completion entails.
*   Payment schedule based on calendar dates instead of acceptance.

## Illustrative Example: Retail Chain

This scenario is hypothetical and illustrative. A retail chain signed an SOW that included "customer data migration from an existing system." The organization assumed the migration included duplicate cleansing; the vendor assumed they were migrating what was provided to them.

In reality, hundreds of thousands of records with duplicates were migrated. Both parties read the same sentence and interpreted it oppositely. There was no line in the contract defining what constituted a valid record.

The correction made in subsequent agreements by that same chain was brief: an appendix defining a measurable quality threshold for loading—a validation pass rate for records, duplicate identification rules, and who approves. This appendix replaced dozens of hours of debate.

## What to Check Before Signing

*   Every deliverable in the proposal appears in the SOW with acceptance criteria.
*   Every assumption presented in the proposal appears as an explicit assumption in the contract.
*   The payment schedule is linked to acceptance.
*   There's an exit clause and a knowledge transfer clause.
*   The defect definition is clear enough to resolve a borderline case.

What was agreed upon during proposal comparison but not included in the contract simply doesn't exist. The comparison process itself is detailed in the [Salesforce Proposal Comparison Guide](/en/insights/compare-salesforce-proposals), and the basis for formulating requirements is established in the RFP document, as detailed in the [Salesforce RFP Guide](/en/insights/salesforce-rfp-guide).

## Connection to Vendor Selection

Some clauses here also serve as evaluation tools: a vendor who objects to a documentation ownership clause or an exit clause tells you something about their operating model. The combination of professional evaluation and contractual readiness is scored together in the [Salesforce Vendor Scorecard Guide](/en/insights/salesforce-vendor-scorecard), and the broader criteria for vetting a company are consolidated in the [Choose a Salesforce Implementation Company Guide](/en/insights/choose-salesforce-implementation-company). Aligning the type of engagement with the type of service purchased is detailed in the [Salesforce Services Guide](/en/insights/salesforce-services-guide).

## Next Step

Take the SOW in front of you and mark every instance where "will be delivered" or "will be performed" appears without an accompanying explanation of how to know when it has happened. Each such mark represents a potential conflict, and each one takes five minutes to fix now.

### Questions and answers
**What's the difference between a Master Service Agreement and an SOW in a Salesforce project?**
A Master Service Agreement (MSA) governs the legal relationship: confidentiality, liability, insurance, intellectual property, payment terms, and dispute resolution. The Statement of Work (SOW) outlines the project's specifics: deliverables, milestones, acceptance criteria, assumptions, and scope. A single MSA can cover multiple SOWs, which is ideal for phased project delivery.

**Who owns the code and configuration built in a Salesforce project?**
This is determined solely by the contract. Some vendors default to the client owning specific project deliverables, while the vendor retains ownership of generic components and underlying infrastructure, often providing a usage license. It's crucial to ensure this license is perpetual and not contingent on continued engagement, preventing issues if you switch providers.

**What's a reasonable warranty period after a Salesforce go-live?**
Typically between thirty and ninety days, depending on project complexity. More important than the duration is the definition: distinguishing between a defect (corrected without charge) and a change request. Practically, any discrepancy between actual behavior and the approved acceptance criteria constitutes a defect; everything else is a change.

**How can an SOW protect against vendor staff changes?**
List key personnel by name and their allocation percentage. Mandate advance notice for any changes and require replacement by equally qualified professionals, subject to client approval. Including provisions for a minimum handover period is also beneficial. While this won't prevent staff departures, it transforms them from a surprise into a managed process.

**What should be included in a project termination or exit clause?**
A comprehensive exit clause should detail: a list of deliverables to be provided, the delivery format, a transition period, transfer of access and environments, and the cost for transition support hours. Without such a clause, terminating an engagement can become a negotiation from a weak position, as the expertise and access reside with the other party.

---

## Salesforce Vendor Scorecard: Criteria & Weighting for Success
URL: https://hpi.pro/en/insights/salesforce-vendor-scorecard
Without a structured scoring model, vendor selection committees often justify decisions in hindsight. A predefined scorecard clarifies evaluation metrics, evidence required for each score, and immediate disqualifiers. This guide presents a seven-dimensional model with example weightings and a fair scoring process to prevent bias.

## Why Selection Committees Are Often Right for the Wrong Reasons

In a typical decision-making meeting, after three presentations, participants often utter phrases like, "I was impressed by them," or "They seemed the most professional." Sometimes the choice is correct. The problem is there’s no way to know—and no way to explain the decision a year from now, when the project inevitably hits complications.

A scorecard isn't meant to replace judgment. It’s designed to ensure that all bidders are evaluated on the same criteria, that the evidence for each score is documented, and that what the committee deemed important before seeing the presentations remains the guiding factor afterward.

## Seven Dimensions of Evaluation

**1. Understanding the Problem.** Does the proposal address your specific processes and volumes, or is it generic? Did the bidder identify a contradiction or gap in the Request for Proposal (RFP)?

**2. Quality of Architectural Proposal.** Is there a diagram? Are truth sources defined? Were alternatives considered, and was it explained why they were rejected?

**3. The Actual Team.** Who is leading the project? How much time are they dedicating? Who is performing the work, and what is the proportion of senior professionals involved in key decision-making stages?

**4. Relevant Experience.** Not just the number of projects, but their similarity in terms of industry, integration complexity, scale, and regulatory environment.

**5. Operating Model and Governance.** The frequency of demos, decision management, risk management, and how changes are handled.

**6. Knowledge Transfer and Autonomy.** Is there an explicit plan that will enable you to maintain the system without their ongoing involvement?

**7. Commercials.** Normalized price, engagement model, contractual flexibility, and willingness to include protective clauses.

## Sample Weights – and How to Adjust Them

| Dimension | New Project in Organization with No Team | Rescue Project | Expansion in Organization with Strong Team |
| --- | --- | --- | --- |
| Understanding the Problem | 20% | 25% | 15% |
| Architecture | 20% | 20% | 25% |
| Actual Team | 15% | 20% | 15% |
| Relevant Experience | 10% | 10% | 10% |
| Operating Model & Governance | 10% | 10% | 10% |
| Knowledge Transfer | 10% | 5% | 5% |
| Commercials | 15% | 10% | 20% |

This table illustrates a principle: weights are not fixed but derive from the dominant risk. In an organization without an internal team, knowledge transfer holds more weight. For a project rescue, understanding the situation and the team's identity are more crucial.

Establish these weights **before** receiving proposals and publish them in your RFP, as detailed in our [Salesforce RFP guide](/en/insights/salesforce-rfp-guide).

## Scoring Scale with Required Evidence

The problem with a 1–5 scale is that everyone tends to score a 4. The solution is to associate each level with specific evidence:

| Score | Meaning | Required Evidence |
| --- | --- | --- |
| 1 | Not addressed | The topic does not appear in the proposal |
| 2 | Generic | Template text with no specific reference to the organization |
| 3 | Adequate | Correct reference but without depth or alternatives |
| 4 | Good | Specific reference with justification and example |
| 5 | Excellent | Alternatives considered, risk identified, and recommendation against something you requested |

The evidence for a score of 5 is what makes this model useful: a vendor who says, "You shouldn't build this part right now," demonstrates an understanding that cannot be faked.

## Disqualification Conditions – Before Scoring

Some factors are not worth weighting because they are grounds for disqualification:

- Refusal to assign ownership of deliverables and documentation to the organization.
- Refusal to name team members and their allocation percentages.
- Non-compliance with mandatory regulatory or information security requirements.
- A proposal that does not adhere to the defined pricing structure, after being given an opportunity to correct it.
- Unwillingness to include a basic exit clause.

Define these upfront. A disqualification made retrospectively always appears to be unfairly targeting a specific bidder.

## Scoring Process to Minimize Bias

1. Each committee member scores **independently** before the joint discussion.
2. The score is accompanied by a brief comment referencing its source in the proposal.
3. Discussion focuses only on significant discrepancies between scorers—that’s where the valuable information lies.
4. Pricing is revealed at this stage and not before, if the process allows for it.
5. The final score is documented along with its rationale.

The fourth step has the most significant impact. A committee that has seen prices before scoring quality will, almost unconsciously, score quality in alignment with the price.

## Illustrative Example: Commercial Security Company

This scenario is hypothetical and illustrative. A selection committee scored four bidders. The proposal that received the highest score for "Relevant Experience" received the lowest score for "Understanding the Problem" because the document it submitted was almost identical to one submitted for another project, including an irrelevant industry name.

During the discussion, an argument was made that the experience compensates for this. The committee referred back to the weights it had set two months prior, where "Understanding the Problem" was given twice the weight of "Relevant Experience." The decision remained unchanged.

What the model prevented here was not necessarily a wrong choice, but a change of the rules after the outcome was already known.

## What to Do with the Outcome

The score is not the decision itself. It's a document that facilitates a productive conversation: where are the significant gaps between bidders, what is missing from the leading proposal, and what risks remain open. Often, the most beneficial outcome is a list of contractual conditions, rather than just a choice between providers.

The commercial aspect is normalized separately before scoring, as detailed in our [Salesforce proposal comparison guide](/en/insights/compare-salesforce-proposals), and the relationship between cost structure and the commercial score is explained in our [Salesforce implementation cost guide](/en/insights/salesforce-implementation-cost).

## Integration with the Professional Interview

Scoring based solely on documents has limitations. A crucial complement is a meeting where you ask the vendor open-ended questions and observe their real-time thought process. A comprehensive set of questions is available in our [guide on questions to ask before choosing a Salesforce integrator](/en/insights/questions-before-choosing-salesforce-integrator), and general criteria for evaluating a company can be found in our [guide to choosing a Salesforce implementation company](/en/insights/choose-salesforce-implementation-company).

## Next Steps

Put your weighted criteria on paper before you read the first proposal, and have each committee member score independently. These two steps, taking a combined hour, improve the quality of the decision more than any additional round of presentations.

### Questions and answers
**What weight should pricing carry in Salesforce vendor selection?**
For projects where outcomes depend heavily on decision quality, a 20-30% weighting for price is common and sufficient. Higher weighting turns it into a price-based decision, while too low can disconnect it from budget realities. More crucial than the weight itself is ensuring the scored price is normalized to the same scope.

**Who should be on the Salesforce vendor selection committee?**
Include a procurement representative, the primary process owner, a technology expert who will maintain the system, and a financial representative. An typical size is four to six members. Larger committees tend to produce average scores that don't differentiate between proposals. It's better to involve additional stakeholders as advisors rather than scorers.

**Are interviews with past clients truly valuable?**
Yes, if you ask the right questions. Satisfaction-focused questions yield polite, uninformative answers. Questions that provide real insight are: What went wrong and how did the vendor respond? Who was the project manager and what made them effective? What would you do differently next time? It's often better to ask about a complex project rather than a flagship one.

**What if two vendors receive nearly identical scores?**
Do not add new criteria in hindsight, as this is precisely when personal preferences can creep in. The correct approach is a focused follow-up: present both with the same short scenario, ask the same question about risk management, and evaluate the actual team members. The difference revealed here is usually clearer than any spreadsheet.

**Is a large vendor or a boutique firm better for a Salesforce project?**
The answer depends on the type of risk that concerns you most. A large vendor offers depth of resources and continuity, often at a higher price and with less flexibility. A boutique firm offers direct access to leadership and agility, with the risk of reliance on a few key individuals. Both risks can be explicitly scored rather than making decisions based on perceived size.

---

## Salesforce API Limits: Designing for Scale and Resilience
URL: https://hpi.pro/en/insights/salesforce-api-limits-resilience
Salesforce tracks API calls within 24-hour windows, and exceeding the threshold causes a hard block, not just a slowdown. An organization running nightly syncs, inbound webhooks, and concurrent reporting needs a carefully planned API call budget, not just 'retry' logic after exhaustion. This guide breaks down real-world limits: how to measure consumption, when to switch to Bulk API, and how to build a backoff strategy that prevents a cascading failure effect.

## What Breaks First When API Limits Are Ignored

A company running three integrations concurrently—a nightly ERP sync, a webhook from a payment system, and an external dashboard pulling data every five minutes—doesn't fail gradually. It works perfectly until it crosses a threshold, then every additional API call is rejected with a `REQUEST_LIMIT_EXCEEDED` code until the daily reset. There's no built-in early warning to prevent this preemptively—only a dashboard you can look at, if someone has built a process to check it.

This type of failure differs from most Salesforce project failures because it's not dependent on bad code or poor design. It's dependent on accumulation: a new integration is always built against the current state, without checking how much of the daily budget is already consumed by existing processes. The result is that the fifth integration "breaks" the four that preceded it, even though none of them changed.

## The Practically Relevant Limit Map

Not every Salesforce Limit matters equally for integration planning. The ones that truly dictate architecture are:

| Limit Type | What It Measures | Who It Affects First |
| --- | --- | --- |
| Daily API Requests | Total REST/SOAP calls in 24 hours | Any high-frequency synchronous integration |
| Bulk API Batches | Number of open/daily batches | Nightly batch processes importing historical data |
| Concurrent Long-Running Requests | Calls running over 20 seconds concurrently | Heavy reports or complex synchronous Apex |
| Platform Event Delivery | Volume of events per day per subscriber | Event-Driven architectures between Salesforce and external systems |
| SOQL Rows per Transaction | Rows retrieved in a single transaction (50,000) | Apex logic running queries inside a loop |

This table isn't generic documentation—it's a prioritization. An organization planning a new integration should first examine the first two rows, as these are the ones that actually get blocked in production. Other limits primarily affect performance, not availability.

## Request Budget: How to Build It Right

The central tool for preventing blocking isn't reactive monitoring but a predefined budget for each API consumer. The principle: every external system, every Integration User, and every scheduled process receives a defined allocation from the overall quota, not "as much as needed."

Building the budget involves three steps:

1. **Consumer Mapping** - A list of every process that calls the API: external integrations, Scheduled Apex, manual Data Loader, BI tools. Each should have a separate Integration User so consumption can be isolated in Event Monitoring.
2. **Load Calculation by Business Volume, Not Assumption** - How many records are processed daily, how many calls are required per record (including fetching Related Lists), and what happens during peak times (quarter-end, Black Friday, month-end close).
3. **Reserve Allocation** - Don't divide 100% of the quota among existing processes. Keep 15%-20% as a reserve for emergency processes, ad-hoc reports, and maintenance—otherwise, any small addition pushes the organization into overuse.

For those interested in delving deeper into designing the layer that manages this budget at the platform level, read the [CRM Architecture Guide](/en/insights/crm-architecture-guide), which presents the division between the integration layer and the business layer.

## REST vs. Bulk: When the Switch Pays Off

The most common mistake is using the standard REST API for high-volume data traffic, because it's built first and works for a PoC. The problem arises when volume grows: REST counts each request (up to 200 records in Composite) as a separate call against the quota, while Bulk API 2.0 runs batches of up to 10,000 records and is counted at a significantly lower cost per record.

A practical rule of thumb: if a single process updates over approximately 2,000 records in one run, switching to Bulk API almost always pays off—even if it means changing the consumer code to work asynchronously with job status polling instead of an immediate response. The price is higher latency (minutes instead of seconds), so Bulk is not suitable for processes requiring real-time decisions, such as inventory checks before order approval.

## Backoff and Retry: Preventing Self-Inflicted Overload

When an API call fails due to a Limit block, the instinctive response of most teams is to try again immediately. This is precisely the behavior that turns a temporary block into a prolonged outage: if ten processes retry at the same moment, they push the system deeper into the block instead of allowing it to recover.

A proper Backoff mechanism requires three components together:

- **Exponential Backoff** - The waiting time between retries increases exponentially (e.g., 2, 4, 8, 16 seconds), not linearly.
- **Jitter** - A small random addition to the waiting time, so that parallel processes don't retry at the exact same second and create a new wave of load.
- **Circuit Breaker** - After a certain number of consecutive failures (e.g., five), the process stops trying completely for a defined period and reports to monitoring, instead of continuing to "knock on the door."

Without a Circuit Breaker, a process running every five minutes and consistently failing will continue to try a hundred times a day and consume quota on failures alone—which is the exact opposite of what the mechanism is meant to prevent. Further details on error handling at the integration level can be found in [Salesforce Integration Error Handling](/en/insights/salesforce-integration-error-handling).

## Scenario: Retail with Three Integration Points

Consider a medium-sized retail chain, about 40 branches, operating Salesforce Service Cloud against a POS system and an ERP system for inventory. Three active integrations: inventory sync every 15 minutes from the ERP (approx. 8,000 SKUs), a webhook from the POS for every failed transaction (approx. 300 per day), and an external Power BI dashboard pulling service data hourly.

The month the chain added a new loyalty program, a fourth integration came online: real-time credit point lookup against Salesforce from every register, adding about 6,000 more calls daily. Within two weeks, inventory syncs started failing around 2-3 PM, peak hours for the registers. The team initially checked the ERP, thinking the problem was there, but the Salesforce log showed `REQUEST_LIMIT_EXCEEDED` precisely during that window.

The solution wasn't to buy more quota, but to change priorities: credit point lookup transitioned to using Platform Cache for results that don't change frequently, reducing calls by about 70%, and inventory sync moved from REST to Bulk API, running every 30 minutes instead of 15. The result: the same business coverage, about 45% lower quota consumption, and a real reserve for the next growth phase.

## Risks and Specific Preventive Actions

| Risk | How It Manifests in Production | Preventive Action |
| --- | --- | --- |
| New integration not checked against existing budget | Blocking appears only after Go-Live | Require a Capacity Review for every new integration before Go-Live |
| Retry without Backoff | Temporary block becomes an hours-long outage | Exponential Backoff with Jitter and Circuit Breaker in every API consumer |
| Using REST for large volumes | A single process consumes tens of percentages of the daily quota | Switch to Bulk API above a predefined volume threshold |
| No separation of Integration Users | Cannot determine which integration consumes the quota | Dedicated Integration User for each external system, monitored separately |
| Lack of reserve in the budget | Any small addition pushes into overuse | Allocate 15%-20% of the quota as a permanent reserve not allocated to daily processes |

## Checklist Before Adding a New Integration

- ☐ Current daily quota consumption is known, by Integration User
- ☐ Peak volume (not average volume) of the new integration has been assessed
- ☐ REST vs. Bulk API decided based on volume threshold, not development convenience
- ☐ Backoff mechanism with Jitter and Circuit Breaker exists in the consumer code
- ☐ An alert is configured for when daily quota consumption exceeds 70%
- ☐ Potential use of Platform Cache to reduce repetitive calls has been evaluated
- ☐ A reserve of 15%-20% of the quota has been set aside and is not pre-allocated
- ☐ An operational owner who receives alerts, not just a technical log, has been defined

## How to Monitor This Continuously

Reliable measurement requires combining three sources: Event Monitoring (or Shield Event Monitoring) for actual API consumption by user, Apex Limits within the code itself (`Limits.getLimitApiRequests()`) for local runtime checks, and the built-in dashboard under Company Information that displays consumption against quota at the organization level. None of the three is sufficient alone: the first shows trends, the second prevents failure within a single process, and the third serves as a daily snapshot for the operations team.

A metric worth tracking over time isn't just "how much was consumed" but "what is the monthly growth rate in consumption"—because this is what allows predicting when the organization will hit the limit, instead of reacting after the blockage has already occurred. When several systems are interdependent, it's also worth examining the overall integration pattern against [Connecting Salesforce to ERP Systems](/en/insights/salesforce-erp-integration), and the question of implementation—Flow vs. Apex—which also affects call efficiency, in [Salesforce Flow or Apex](/en/insights/salesforce-flow-vs-apex).

## Summary

Salesforce API Limits are not a problem to be solved once discovered—they are a variable that must be part of every integration decision from day one. A documented request budget by Integration User, conscious choice between REST and Bulk based on volume, and a Backoff mechanism that prevents self-inflicted overload—these three together distinguish an organization that discovers the problem only when already blocked, from an organization that sees it approaching a month in advance and acts in time.

### Questions and answers
**How many API calls does a Salesforce org receive, and how does it reset?**
Daily API quotas are determined by your Salesforce edition and licensed users, resetting every 24 hours at a fixed time, not necessarily midnight server time. The 'Additional API Calls' add-on provides fixed bundles for increased needs, but it's a short-term fix. If consumption grows with every new integration, the issue is architectural, not merely quantitative.

**What's the practical difference between standard REST API and Bulk API in terms of limits?**
The REST API counts each individual call against your daily quota. Updating 50,000 records consecutively could consume a significant percentage of your budget alone. Bulk API 2.0 works in batches and is counted far more efficiently per record but operates asynchronously. Your consuming code must adapt to polling for Job status rather than expecting immediate responses.

**What should be done when a critical business process receives a REQUEST_LIMIT_EXCEEDED error?**
Immediately stop the requesting thread and do not retry instantly with the same intensity. Implement Exponential Backoff with Jitter, push the request to a waiting queue, and alert the operations team if the blockage persists beyond a predetermined threshold. Continuously trying at a fixed rate only prolongs the lockout and jeopardizes other processes sharing the same quota.

**Are Platform Events or Change Data Capture counted toward the API quota?**
Events published via Platform Events and consumed by CometD are not counted as standard API calls. This makes them an efficient way to stream real-time updates without consuming your daily quota. However, any REST API calls made by the consumer in response to an event—such as fetching full record details—will count toward the limit. Therefore, consider including necessary fields directly within the event payload.

**How can we preemptively know if a new integration will push the organization over its limits?**
Perform a simple forecast: estimate daily record volume multiplied by calls per record (including related records and lookups fetched separately), then compare this to the remaining budget after existing integrations. If the result exceeds 70-80% of your total quota, plan for Bulk API, caching, or field reduction before going live—not after the first lockout.

---

## Salesforce Event-Driven Architecture: Platform Events vs. Change Data Capture
URL: https://hpi.pro/en/insights/salesforce-event-driven-architecture
Platform Events and CDC solve a critical challenge: decoupling systems so they don't have to wait for each other. The real problem arises when you choose between them based on technical convenience rather than data ownership, required reliability, or how to handle duplicate or lost messages.

## The Choice That Isn’t Really About Technology

When an organization starts discussing Event-Driven Architecture in Salesforce, the conversation often too quickly veers towards "Platform Events or CDC?"—as if it's solely a tools question. In reality, it's a completely different inquiry: which side of the integration is the source of truth, what can it afford to lose, and who bears the cost when a message arrives late, duplicated, or not at all.

The short answer: Change Data Capture (CDC) is suitable when an external system needs to know that Salesforce updated a row, and there's no need to wrap that in business logic. Custom Platform Events are ideal when you want to publish a meaningful business event—"customer upgraded plan," not "Status_c field changed." The wrong choice isn't apparent on launch day; it becomes clear when someone needs to reconstruct what happened after a partial failure and discovers there's no reliable way to know.

For a broader perspective on Salesforce integrations beyond events, refer to the [CRM Architecture Guide](/en/insights/crm-architecture-guide).

## Three Questions That Define Architecture Before Writing a Line of Code

Before choosing a mechanism, you need answers to three questions. Skipping any of them is the most common reason integration projects get stuck in the testing phase.

**Who owns the data?** If Salesforce is the source of truth for the customer record, outbound events from Salesforce (Platform Events or CDC) are the natural direction. If the ERP system is the owner, the opposite is true, and Salesforce should consume events rather than publish them for that same entity.

**What can be lost?** An alert to an executive dashboard can lose a single message without harm. A credit limit update before transaction approval cannot. This distinction determines whether a "fire-and-forget" approach is sufficient or if an acknowledgment and reconciliation mechanism is required.

**What happens if the message arrives twice?** Platform Events guarantee At-Least-Once, not Exactly-Once. If the answer is "we don't know"—the solution isn't production-ready, regardless of how clean the code is.

## Platform Events vs. CDC — Decision Table

| Criterion | Custom Platform Event | Change Data Capture |
| --- | --- | --- |
| What is Published | Defined business event (custom payload) | Raw row change (before/after) |
| Who Builds the Logic | Salesforce developer, during Trigger or Flow | The platform, automatically for any defined DML |
| Schema Coupling | Low — payload is controlled by the publisher | High — any change to the object structure affects the consumer |
| Suitable When... | You want to publish business intent ("Order Approved") | You want raw data synchronization between systems |
| Maintenance Cost | Higher initially (building payload and logic) | Lower initially, higher when object structure changes |
| Retention | Based on license definition (hours to days) | Based on license definition, often same as Platform Events |
| Recommended Volume | Medium-frequency domain events | Row-level changes, including high frequency |

Practical rule of thumb: If the event consumer needs to understand "why" it happened, not just "what" happened, then a custom Platform Event is necessary. If the consumer merely needs an updated copy of the data, CDC saves an entire development layer.

## Ordering, Replay, and Idempotency: The Three Concepts That Turn Theory into Stable Production

These are not topics for the late stages of a project—they dictate the consumer's structure from day one.

**Ordering.** Platform Events are sent in publication order within the same topic, but load and partial failures can disrupt the reception order on the consumer side. Practical solution: include a version stamp or sequence number from the original record with each event, and allow the consumer to reject an event whose version is older than the last one already processed.

**Replay.** Each event receives a Replay ID. A consumer that crashes should store the last successfully processed Replay ID—not in memory, but in persistent storage (Custom Object, external table)—and resume from there during recovery. Relying on "the system will start from scratch" only works within the retention window, and beyond that, events are lost.

**Idempotency.** Every consumer needs to identify an already processed event, typically by a unique transaction ID sent within the payload. Without this, automatic retries on the sender side—or manual replay after a failure—result in double updates, duplicate record creation, or in the worst case, double billing.

This gap almost never shows up in a demo. It emerges under load, during an actual network failure, or a change in the production environment, and by then, the cost to fix it also includes data correction. Organizations encountering a similar issue in their automation layer can find a complementary analysis in [Salesforce Flow and Apex Technical Debt](/en/insights/salesforce-flow-apex-technical-debt).

## Example Scenario: Retail Chain with 40 Branches and Separate Inventory System

Consider a hypothetical retail chain, "North Retail," operating Salesforce Sales Cloud for sales teams across 40 branches, and a separate ERP system managing real-time inventory. Until now, every order closed in Salesforce was transferred to the ERP via a scheduled job running every 15 minutes—a solution that sometimes led to sales reps seeing outdated inventory and approving orders for out-of-stock products.

The architecture team decided to publish a custom Platform Event named `Order_Confirmed__e` upon every order confirmation, with a payload that includes a unique transaction ID, item list, and quantities. The ERP listens for the event and updates inventory within seconds, checking the transaction ID against a table of already processed transactions—to prevent double deduction if the event arrives twice.

Additionally, a nightly reconciliation process was established to compare the total orders confirmed in Salesforce with the total updates received in the ERP, alerting to any discrepancy above a defined threshold. The reason: even with proper idempotency, early detection of extended network failures is desired, rather than solely relying on the event "surely arriving." The result: update time dropped from 15 minutes to less than a minute, and the number of incorrect inventory incidents measurably decreased within one month of implementation.

This scenario illustrates a key principle: value isn't created merely by "moving to events" itself, but by combining a clear business event, duplicate checking on the consumer side, and a monitoring process that identifies discrepancies before they become customer complaints.

## Common Risks and Preventive Actions

| Risk | How it Manifests | Preventive Action |
| --- | --- | --- |
| Publishing an event for every field change | Daily event limits exceeded within days | Publish meaningful business domain events, not technical events for every DML |
| No duplicate checking on the consumer side | Retries or replays create duplicate records or updates | Include a unique transaction ID and check it before any action |
| Reliance on arrival order | An older update overwrites a newer update | Include a version stamp and reject events older than the last processed version |
| No Replay ID persistence | After consumer crash, events between crash and retention window are lost | Store Replay ID persistently and implement automatic replay upon restart |
| CDC on an frequently changing object structure | Every field change breaks the external consumer without warning | Define an explicit data contract and communicate schema changes in advance |
| No business monitoring, only technical monitoring | Integration is "green" but actual inventory or orders don't match | Add daily reconciliation that compares business outcomes between systems |

## Checklist Before Starting Event Layer Development

- ☐ Each event has a clear owner: who publishes and who is the business owner of the data
- ☐ A consistent and documented payload is defined, not a structure that changes with every sprint
- ☐ A choice has been made between custom Platform Events and CDC based on business intent versus raw change
- ☐ Each consumer has a unique transaction ID and duplicate checking (Idempotency)
- ☐ Order handling is defined by version stamp, not by arrival order
- ☐ Replay ID is stored persistently, and a recovery process is defined and tested
- ☐ Business monitoring (Reconciliation) exists in addition to technical message queue monitoring
- ☐ Load and partial failure scenarios have been tested, not just the happy path
- ☐ Daily event limits (Publish + Delivery) have been checked against expected production volume
- ☐ An operational owner is defined to respond when a reconciliation discrepancy is found

## How to Measure Architecture Effectiveness

| Area | What to Measure | Measurement Frequency |
| --- | --- | --- |
| Delivery Reliability | Percentage of events completed without retry, and percentage successful after retry | Continuous |
| Reconciliation Discrepancies | Difference between records confirmed in source and records received in target | Daily |
| End-to-End Latency | Time from business event to actual update at the consumer | Continuous |
| Event Limit Utilization | Percentage of daily quota actually used | Weekly |
| Duplicates Prevented | Number of events identified as duplicates and blocked before execution | Weekly |

It's recommended to choose no more than three to four metrics for the initial version and measure them against a baseline collected before transitioning to event architecture—not against a general feeling that "it's faster now."

For broader organizational planning of multiple integrations, also consider [Salesforce Integration Patterns](/en/insights/salesforce-integration-patterns) and their implications for [Single Org vs. Multi Org Architecture](/en/insights/salesforce-single-org-vs-multi-org), as event decisions often cross organizational boundaries.

## Summary

The choice between Platform Events and CDC is not a short-term technical question at the project's start—it determines the source of truth, what can be lost, and how the system behaves when something goes wrong in the middle. An organization that plans ordering, replay, and idempotency in advance, and adds a business reconciliation layer in addition to technical monitoring, achieves an integration that withstands load and partial failure. An organization that skips these steps gets a system that looks fine in testing but silently breaks in production, usually without anyone noticing until the damage is already done.

Organizations seeking guidance in building a reliable event layer in Salesforce can reach out through our [CRM Architecture service](/en/crm-architecture).

### Questions and answers
**When is Change Data Capture (CDC) preferable over a custom Platform Event?**
CDC is ideal when Salesforce is the single source of truth, and a target system needs to know a record has changed without custom logic explicitly publishing it. CDC eliminates that layer but exposes the object's internal structure; any field change affects subscribers. A custom Platform Event is better when you want to publish a business-level intent ('Order Approved') rather than a technical row change.

**Do Platform Events guarantee a message will be delivered only once?**
No. The Salesforce platform guarantees at-least-once delivery, meaning a message might arrive multiple times due to network glitches or replays. Consumers *must* be designed for idempotency. This means checking a unique transaction ID before processing to prevent duplicate updates, record creation, or charges. This is a crucial design consideration, not an exceptional failure.

**What happens if an event consumer is unavailable for several hours?**
Platform Events are retained in the Event Bus according to a license-defined retention window (typically 24 hours to 3 days). You can perform a replay from the last successfully received Replay ID. It's critical for the consumer to store its last processed Replay ID. If the retention window expires before a replay, events are permanently lost.

**How do you maintain event order when multiple events pertain to the same record?**
Platform Events do not guarantee order across different channels, and sometimes not even within the same channel under heavy load. A common solution is to add a version or sequence number to each event, allowing the consumer to disregard updates that arrive with an older version than what has already been processed, rather than relying on arrival order.

**How many Platform Events can be published without impacting performance?**
Limits are measured by daily event publishes and daily deliveries, dependent on your Salesforce edition and license. This includes events that failed to send. Projects that publish an event for every field change on a busy table will quickly hit these limits. Therefore, it's best practice to publish 'domain events' representing business significance, not technical DML changes.

---

## Salesforce SSO, MFA, & Identity: Enterprise Design Principles
URL: https://hpi.pro/en/insights/salesforce-sso-identity-architecture
SAML or OIDC, IdP-initiated or SP-initiated, JIT or SCIM for lifecycle management – every Identity architecture decision for Salesforce dictates who accesses your system, with what permissions, and what happens the day they leave. This article outlines a concrete decision framework, including a scenario where offboarding fails and how to fix it.

## The Short Answer

Salesforce identity architecture isn't a one-time technical project; it's a daily control layer that governs who logs in, with what identity, which permissions they hold, and what happens when they should no longer have access. The choice between SAML and OIDC, JIT and SCIM, and between IdP-level MFA policies and internal Salesforce enforcement—these may seem like minor configuration details. In reality, they determine how long it takes to block access for a terminated employee and what percentage of such incidents will only be discovered during an audit.

The correct approach doesn't start with the protocol, but with two fundamental questions: Who is the single source of truth for user identity, and what is the maximum permissible time between an offboarding event and the actual blocking of access? All other decisions—federation type, provisioning method, session policy, and the Break Glass process—stem from these answers.

Organizations also grappling with permission-related questions, not just authentication, can find more information in the [Salesforce Permission Model](/en/insights/salesforce-permission-model).

## Decision Map: Four Layers of Identity in Salesforce

| Layer | Key Question to Decide | Main Options | What Breaks If Decided Incorrectly |
| --- | --- | --- | --- |
| Federation and Authentication | Who is the Identity Provider and how does Salesforce trust it? | SAML 2.0, OIDC, Delegated Authentication | Dual login, attribute mismatch, trust breach |
| Provisioning and Lifecycle | How is a user created, updated, and deactivated? | JIT Provisioning, SCIM, Manual Creation | Orphaned accounts, lingering access after departure |
| Session and MFA | Where are authentication strength and session duration enforced? | IdP MFA, Internal Salesforce MFA, Session Policies | MFA bypass via alternative path, perpetually active session |
| Break Glass and Audit | What happens when SSO fails, and who audits exceptions? | Controlled emergency user, Login History, Event Monitoring | Absolute reliance on IdP, inability to investigate retrospectively |

## SAML vs. OIDC: Not a Question of "What's Newer"

The choice between these two protocols should not be driven by trends but by existing infrastructure. SAML operates with XML and signed assertions, commonly found in organizations with Active Directory Federation Services or a legacy IdP already serving dozens of other systems. OIDC, built on OAuth 2.0, is lighter to maintain and particularly convenient when the same IdP needs to serve modern API consumers alongside user logins.

A common mistake is choosing based on what seems "advanced" without verifying which attributes the existing IdP already sends and how they map to Salesforce (Username, Federation ID, Profile, Permission Set Group). Incorrect attribute mapping during setup often leads to manual correction of dozens of users in production, rather than just a configuration change.

A forgotten point: even when choosing OIDC or SAML, it's advisable to plan IdP-initiated versus SP-initiated login separately. Many common security incidents arise because SP-initiated access remains open, even though all login processes were designed to go through the IdP portal exclusively.

## JIT Provisioning vs. SCIM: When "Just-in-Time" Isn't Enough

JIT (Just-In-Time) Provisioning creates or updates the user in Salesforce upon their first login, based on data received from the IdP in a SAML Assertion or OIDC Token. This is convenient, inexpensive to implement, and sufficient for most organizations where users log in regularly.

The problem: JIT doesn't handle deprovisioning. If an employee is removed from the IdP but doesn't log in again, their user account remains active in Salesforce indefinitely because no event triggers an update. This is precisely where SCIM (System for Cross-domain Identity Management) comes in—it enables proactive synchronization from the IdP to Salesforce, including immediate deactivation when a user is removed at the source.

The practical rule: If an organization requires offboarding within hours rather than days—for contractors, temporary employees, or access to sensitive data—SCIM is not a nice-to-have but a compliance requirement. If employee turnover is slow and governance already includes quarterly access reviews, JIT alone might suffice, provided it's accompanied by a documented manual process for immediate blocking.

Provisioning planning should always be evaluated against the complexity of its surrounding automation—for example, when Flows running permission assignment logic are involved during user creation, where the comparison in [Flow vs. Apex](/en/insights/salesforce-flow-vs-apex) for where custom code is worthwhile becomes relevant.

## MFA and Session Policy: Two Layers, Not One

A common mistake is to rely solely on MFA enforced by the Identity Provider and assume it covers all Salesforce login paths. In practice, as long as a user can log in directly via login.salesforce.com—such as an integration, API User, or an Admin with backup access—a separate MFA policy defined within Salesforce itself (Identity Verification, Session Security Levels) is required.

Alongside this, session policies determine easily overlooked details: Session Timeout, "Force logout on session timeout," Login IP Ranges, and mandatory High Assurance Session for sensitive operations (e.g., changing permissions or mass data export). An organization that configures strong MFA but leaves Session Timeout at the default two hours creates a window where a stolen computer retains active access long beyond what's reasonable.

## Break Glass and Audit: When SSO Fails, Who Gets In

Complete reliance on an external IdP creates a single point of failure: If the IdP goes down or if there's a bug in the federation configuration, no one, including those who need to fix the issue, can log in. The common solution is a Break Glass user—a super-admin account with independent authentication (not reliant on SSO), a password managed in a vault, not a person's memory, and separate MFA.

It's important to distinguish: Break Glass is not a "convenient back door"—it's a controlled emergency mechanism. Its use must trigger an automated alert and be reviewed within one business day by someone other than the user who accessed it. Many organizations set up the user correctly but overlook ongoing oversight—the password remains unrotated, and its permissions are overly broad by default.

## Organizational Scenario: Offboarding Failure at a Mid-sized Insurance Company

Consider an insurance company with approximately 600 employees, using Okta as its Identity Provider and a SAML configuration with Salesforce established about three years ago. Provisioning is entirely based on JIT: when a new employee logs in for the first time, a user is created with a Profile and Permission Set Group according to their Okta group membership.

In one instance, a service representative was terminated on a Friday afternoon. The IT team immediately deactivated them in Okta. In practice, because there was no SCIM mechanism or webhook to synchronize deactivation to Salesforce, their user remained active there—and because their session was already active from that morning and "Force logout on session timeout" was not configured, they continued to access the system even after termination, until someone noticed during a weekly access review on Monday.

The solution implemented was not a full transition to SCIM (which would have required a separate project and integration budget), but an immediate combination of three actions: enabling "Force logout on session timeout" for all sensitive profiles, shortening Session Timeout from 120 minutes to 30 minutes for customer-facing roles, and adding an automatic step to the organizational offboarding process that performs direct deactivation in Salesforce as an independent action, not just an indirect result of Okta deactivation. SCIM remained a target for the next quarter, with budget and approval already secured, but the most dangerous gap was closed within a week.

## Common Risks and Prevention Actions

| Risk | How it Manifests | Prevention Action |
| --- | --- | --- |
| Full reliance on JIT without deprovisioning | Terminated users remain active indefinitely | Add an independent Salesforce offboarding step, not dependent on sync |
| MFA only at IdP | Integration and Admin users bypass MFA via direct login | Internal Salesforce MFA policy for all user types |
| Overly long Session Timeout | Stolen computer or forgotten open session retains access for hours | Shorten Timeout and Force Logout for sensitive profiles |
| Break Glass without oversight | Emergency account usage goes undetected | Automatic alert and review within one business day for any usage |
| Incorrect IdP attribute mapping | User receives incorrect Profile or Role on first login | Thorough mapping validation in Sandbox environment before production change |

## Checklist for Identity Architecture Setup or Review

- ☐ A single Identity Provider is defined as the source of truth, and what happens when it fails is known.
- ☐ Protocol (SAML or OIDC) is chosen based on existing infrastructure, not trends.
- ☐ Attribute mapping between the IdP and Profile/Permission Set Group is tested in Sandbox.
- ☐ A clear policy is defined: JIT only, or JIT combined with SCIM based on offboarding requirements.
- ☐ MFA is enforced within Salesforce, not just at the IdP.
- ☐ Session Timeout and Force Logout are configured according to profile sensitivity.
- ☐ A controlled Break Glass user exists, with separate MFA and a password in a vault.
- ☐ The offboarding process includes an independent step for deactivation in Salesforce.
- ☐ Login History and Event Monitoring are reviewed on a regular schedule.
- ☐ There is a periodic access review plan that doesn't solely rely on IT's memory.

## How to Measure the Architecture's Effectiveness

The primary metric is not "Is SSO active?" but the response time between an event at the source of truth and a corresponding change in Salesforce: how much time passes between user removal in the IdP and actual deactivation. A complementary metric is the rate of logins performed via an unexpected path (direct login instead of through the IdP), which should approach zero except for documented Break Glass access. A third metric is the frequency of permission reviews against the actual state—not every organizational change comes through the IdP, so quarterly reviews remain essential even with fully automated provisioning.

For implementing or auditing identity architecture in an existing Salesforce environment, progress can be made through [CRM Architecture Services](/en/crm-architecture). Organizations also examining connections to ERP and payroll systems as part of the overall identity picture will find complementary background in [Connecting Salesforce to ERP](/en/insights/salesforce-erp-integration) and a broader architectural overview in the [CRM Architecture Guide](/en/insights/crm-architecture-guide).

## Summary

Salesforce identity architecture is built once but tested daily through isolated incidents—a departing employee, a session that forgets to close, an integration that bypasses MFA. Key choices (SAML vs. OIDC, JIT vs. SCIM, dual MFA, controlled Break Glass) should not be derived from the IdP's default settings but from the required response time to block access and the sensitivity level of the exposed information. An organization that plans this layer in advance, rather than discovering gaps during an audit or after a security incident, saves both remediation costs and reputational and regulatory risks.

### Questions and answers
**What's the practical difference between SAML and OIDC for Salesforce?**
Both are supported as Single Sign-On (SSO) providers. However, OIDC is REST/JSON-based and integrates more seamlessly with modern Identity Providers (IdPs) and other API consumers. SAML is more common in organizations with established IAM infrastructures or regulatory requirements built around it. The choice should stem from your existing IdP, not solely a technical preference. Migrating between the two after attribute mappings and permission sets are built is a non-trivial undertaking.

**When should I use JIT Provisioning versus SCIM?**
Just-In-Time (JIT) provisioning is suitable when it's sufficient to create and update a user upon their first login, and when there's no real need for immediate de-provisioning outside the SSO cycle. System for Cross-domain Identity Management (SCIM) is required when there's an operational mandate to revoke access within minutes of a user being removed from the IdP. This includes organizations with immediate offboarding requirements, temporary contractors, or regulations demanding synchronized proofs between identity sources.

**Is IdP-enforced MFA sufficient, or do I also need MFA at the Salesforce level?**
If all logins go through your IdP and there's no direct login path to Salesforce, IdP-enforced MFA might suffice for regular logins. However, an internal MFA policy within Salesforce is always critical. This covers 'Break Glass' users, integrations with service accounts, and any pathway that circumvents the IdP – otherwise, a security gap emerges precisely in the most vulnerable areas.

**How do you create a 'Break Glass' user that doesn't become a permanent vulnerability?**
A 'Break Glass' user requires a password managed in a secure vault, separate MFA, permissions strictly limited to emergency roles (not a blanket System Administrator), and automatic alerts upon any usage. A mandatory rule is that every login with this user is reviewed within one business day, and a quarterly process ensures the password is rotated even if unused.

**What happens if an employee leaves and the IdP isn't synchronized with Salesforce in real-time?**
Without SCIM or a webhook triggering immediate deactivation, the user remains active in Salesforce even after being removed from the IdP, because an existing session isn't checked against the IdP for every request. The practical solution involves a combination of short session timeouts, Login IP Ranges, and an offboarding process that runs direct deactivation in Salesforce as an independent step, rather than solely relying on slow IdP synchronization.

---

## Salesforce Sharing & Visibility: Designing Robust Data Access
URL: https://hpi.pro/en/insights/salesforce-sharing-visibility-design
An open OWD setup, chosen to 'keep everyone happy,' and an ad-hoc Role Hierarchy are the fastest paths to a report where a regional manager sees all of their internal competitor's customer accounts. This article outlines a reverse workflow: first, map who absolutely needs to see what and why, then strategically choose from OWD, Role Hierarchy, Sharing Rules, Teams, and Apex Sharing.

## Why a Retrospective Sharing Model is Harder Than a Well-Built One

The typical problem doesn't surface in the first month. It emerges when a regional sales manager notices they can see an opportunity from a competitor's territory, or when a service rep opens a VIP customer's case that should only be accessible to a dedicated team. Both scenarios are a direct result of a reversed workflow: defining objects and fields first, and only at the very end asking who should actually see what.

The visibility model in Salesforce is constructed from layers that operate in concert, not independently: Organization-Wide Defaults (OWD) establish the most restrictive baseline, Role Hierarchy adds vertical access based on the managerial structure, Sharing Rules open up horizontal access based on business criteria, Teams and Manual Sharing address individual cases, and Apex Managed Sharing comes into play when the logic is too complex to be expressed using static rules. This order is crucial: every layer chosen prematurely creates technical debt that is difficult to untangle, because permissions already granted are perceived as an existing right.

## Mapping the Layers and When Each is Appropriate

| Layer | What it Solves | When to Choose It | Risk of Incorrect Choice |
| --- | --- | --- | --- |
| OWD | The baseline: who can't see anything by default | Always defined, usually Private for sensitive objects | An overly open OWD renders all other layers redundant |
| Role Hierarchy | Vertical access for a manager to subordinates' information | When the management structure also reflects the need for data oversight | A "political" hierarchy that doesn't align with actual data ownership |
| Sharing Rules | Opening horizontal access based on fixed criteria (role, group, field value) | A cross-hierarchy team needing access to the same record type | A multitude of overlapping rules making it hard to determine who opened what |
| Public Groups | Grouping users for sharing purposes, irrespective of the hierarchy | When a workgroup doesn't align with a single organizational role | Groups that aren't updated when employees change roles |
| Account/Case Teams | Dynamic access to a single record based on its team composition | When each customer or case has a unique, changing team | Manual maintenance that is forgotten when the team changes |
| Territory Management | Assigning access based on dynamic, multi-dimensional rules | Variable assignment based on several attributes simultaneously, parallel access for multiple reps | Maintenance complexity not justified below a certain organizational threshold |
| Apex Managed Sharing | Sharing derived from dynamic logic that cannot be expressed statically | Criteria dependent on calculation, external events, or field combinations | Unmonitored code that continues to run after business requirements change |

## OWD: The Decision That Determines All Others

OWD isn't just a technical security setting—it's an organizational statement about who truly owns the information. The practical rule: set OWD based on the most stringent requirement truly needed, and then open it up using Sharing Rules, not the other way around. The reason is that expanding access specifically is easy and documented, whereas restricting existing access requires organizational communication, because users perceive a loss of access as an infringement, even if it's a correction of a historical error.

A point that often doesn't receive enough attention: OWD is set separately for each object, and dependent objects (Master-Detail) inherit visibility from the primary object. When building a new data model, examine the full dependency chain before setting OWD—otherwise, a "secondary" object mistakenly configured as Public can expose information from the primary object through it.

## Role Hierarchy vs. Actual Management Structure

The most common mistake is duplicating the organizational chart into the Role Hierarchy as-is, without verifying if it accurately reflects the flow of data ownership. A regional manager needs to see their team's opportunities—that's a managerial role. But a CFO doesn't automatically need to see every service case just because they are high up in the overall hierarchy; if such a need exists, it should be addressed with a targeted Sharing Rule, not an overly broad hierarchy.

A sharing hierarchy separated from the organizational reporting hierarchy is a legitimate and often preferable solution, especially in organizations with a matrix structure where managerial reporting doesn't align with customer data ownership.

## Decision Matrix: What Triggers Each Sharing Mechanism

- **Need varies by persistent, predictable role** → Role Hierarchy.
- **Need is shared by a cross-functional workgroup** → Public Group + Sharing Rule.
- **Need varies by team composition on a single record** → Account Team or Case Team.
- **Need depends on a combination of dynamic conditions (geography, product, customer size)** → Territory Management.
- **Need is derived from a calculation, external event, or condition that cannot be expressed statically** → Apex Managed Sharing.
- **Need is a specific, temporary exception for a single record** → Manual Sharing, with oversight and documentation.

This matrix should be drafted *before* working with the tools, not concurrently—otherwise, a mechanism will be chosen based on what the development team is familiar with, rather than what suits the requirement.

## Illustrative Scenario: An Industrial Equipment Manufacturer with Three Sales Channels

Imagine a hypothetical industrial equipment manufacturer with roughly 180 Salesforce users, operating through three channels: direct sales by geographical region, sales through distributors, and sales to global strategic accounts managed concurrently by several reps in different countries.

An initial attempt to use only Role Hierarchy failed: a global strategic account didn't belong to a single regional hierarchy, and a rep in Germany couldn't see updates from their colleague in Brazil on the exact same account. The chosen solution combined three layers: OWD for Account and Opportunity was set to Private; Role Hierarchy was used for regular managerial access within each region; and for strategic accounts, a dynamic Account Team was configured to update automatically via Flow when the "Strategic Account Owner Region" field changed. Distributors received separate access through a Sharing Rule based on a dedicated Public Group, to prevent exposure to direct sales accounts.

The result: Sharing Recalculation time remained stable because most access is derived from a static structure (Role, Public Group), and only a minority of accounts—the strategic ones—depend on dynamic updates. The core lesson: there isn't one "correct" mechanism for the entire organization; rather, the mechanism should be tailored to the type of dependency for each sub-group of records. Further discussion on selecting integration patterns and a supportive data model is available in the [CRM Architecture Guide](/en/insights/crm-architecture-guide).

## Specific Risks in Visibility Planning and Preventive Actions

| Risk | How It Manifests | Preventive Action |
| --- | --- | --- |
| OWD "temporarily" open during pilot phase | The openness persists after the system goes live into production | Establish a predefined closure date and document it as a Go-Live item, not a recommendation |
| Multiple overlapping Sharing Rules | It's impossible to definitively know why a user sees a particular record | Standardized naming for each rule that includes the business reason, and periodic review of unused rules |
| Apex Sharing without load testing | Sharing calculation delays as data volume grows | Conduct load testing on Sharing Recalculation before doubling record volume in production |
| Sharing hierarchy copied from a political organizational hierarchy | Managers see data they have no business need for | Separate the Role hierarchy for sharing purposes from the official reporting hierarchy when they are not identical |
| Manual Sharing accumulates without ownership | Exceptional permissions remain active after the reason for sharing is no longer relevant | Implement an expiration process or quarterly review of manual shares |
| User role change without Public Group updates | Old access remains open, and new access is missing | Integrate group and role updates as a single step in the employee status change process |

## Checklist Before Finalizing the Sharing Model

- ☐ OWD configured for the most restrictive required state, not for development convenience
- ☐ Dependency chain between Master-Detail objects reviewed against the primary object's OWD
- ☐ Role Hierarchy reviewed against actual data ownership, not just an organizational chart
- ☐ Each Sharing Rule has documented business reason and an owner responsible for its validity
- ☐ Assessed whether Territory Management is actually needed or if it introduces unnecessary complexity
- ☐ Apex Sharing code tested under realistic data volume, not just in a small Sandbox environment
- ☐ Process in place for updating Public Groups and permissions upon role change or termination
- ☐ Defined a periodic review cadence for Manual Sharing and inactive Sharing Rules
- ☐ Impact of the sharing model on report performance and large batch runs analyzed
- ☐ Response plan in place for discovering over-exposure in production

## How to Know the Model Withstands Load

The first metric is Sharing Recalculation time after structural changes—a consistent increase over time indicates the model is approaching unmanageable complexity. The second metric is the number of support requests for "I lack access" versus "I have unnecessary access"—a sharp skew in one direction suggests that OWD or Sharing Rules are not properly calibrated. A third metric, particularly crucial in organizations with multiple systems, is the alignment between Salesforce permissions and permissions in synchronized systems—especially concerning event-driven integration architecture, as described in the [Salesforce Event-Driven Architecture Guide](/en/insights/salesforce-event-driven-architecture).

In organizations operating multiple Orgs, the sharing model issue often intersects with the question of whether more than one production environment is even necessary—the full discussion can be found in [Salesforce Single Org vs. Multi Org](/en/insights/salesforce-single-org-vs-multi-org), and in selecting compatible integration patterns in the [Salesforce Integration Patterns Guide](/en/insights/salesforce-integration-patterns).

## Summary

A good sharing and visibility model isn't measured on launch day—it's measured as the organization grows, when a user changes roles, and when someone asks, "Why can't I see this?" The way to achieve this is not to pick one tool and apply it to everything, but rather to map each group of records according to its type of dependency—permanent, horizontal, dynamic, or exceptional—and choose the appropriate mechanism for each. A closed OWD by default, a Role Hierarchy reflecting true ownership, Sharing Rules with documented reasons, and Apex Sharing only when the logic justifies it—this is the combination that endures even when the organization doubles in volume and complexity.

### Questions and answers
**Can we start with an open OWD and restrict it later?**
Technically, yes, but in practice, it almost always backfires. Once users and reporting become accustomed to seeing everything, any future restrictions are perceived as detrimental and meet resistance. The correct approach is the opposite – start with a closed model and open access granularly with Sharing Rules only when a genuine need arises.

**When should I use a Sharing Rule versus Apex Managed Sharing?**
Sharing Rules are suitable when the sharing criterion is derived from a static field or membership in a role/public group. Apex Sharing is required when the criterion depends on runtime logic—for example, sharing based on a combination of fields, the result of a calculation, or an event in an external system.

**Is Territory Management worth the complexity for a medium-sized organization?**
Typically not, unless at least one of the following conditions exists: customer assignments change based on multiple attributes simultaneously (geography, industry, size), concurrent access by several representatives to the same record is required, or the organizational hierarchy and sharing hierarchy are no longer identical. Below this threshold, Role Hierarchy and Sharing Rules are sufficient and simpler to maintain.

**How do you identify when a sharing model is no longer suitable for an organization?**
Practical signs include: Sharing Recalculation times lengthening with each run, recurring support tickets like 'I can't see a record I should see,' increasing use of ad-hoc Manual Sharing as a workaround, and complaints that management reports show different numbers depending on who runs them.

**What happens to the sharing model when a user changes roles or departments?**
Any role change triggers a recalculation of Role Hierarchy Sharing. If Public Group-based Sharing Rules also exist, ensure the user is updated there as well—these two mechanisms do not automatically synchronize. Organizations with frequent structural changes need a defined process, including verifying that old access has been revoked, not just new access granted.

---

## Comprehensive Salesforce Integration Monitoring & Error Handling
URL: https://hpi.pro/en/insights/salesforce-integration-error-handling
Most integration failures impacting customers aren't due to a downed API, but rather a quietly failed message that no one knew to look for. This article breaks down the error handling chain into four layers – Idempotency, Retry, Dead Letter, and Reconciliation – and reveals where each commonly breaks down in practice.

## Why Integrations "Work" in Demo and Quietly Fail in Production

During standard user acceptance testing (UAT), you send a single message, confirm its reception, and approve. In production, that same integration processes thousands of messages daily, and some will inevitably fail—due to timeouts, row locks, expired authorizations, or schema changes in the connected system. The fundamental question for solution quality isn't "Does the integration work?", but rather, "What happens when it *doesn't* work, and who notices?"

Most of the costly failures I've observed didn't stem from bugs in the integration code itself, but from the absence of three critical capabilities: detecting a failed message, a mechanism to retry without creating duplicates, and a process to ensure data consistency between both systems by end-of-day. Without these, any integration "works" until the moment it's discovered it hasn't been working for two weeks.

## Four Layers for Proper Error Handling

| Layer | What it solves | Typical failure without it |
| --- | --- | --- |
| Idempotency | Re-running the same message doesn't create duplicate records | Duplicate orders or inventory movements after a retry |
| Retry with Backoff | Temporary failures (timeout, rate limit) are self-corrected | A momentary surge becomes a persistent issue |
| Dead Letter Queue | Non-temporary failures are flagged, not silently lost | A message is "swallowed," and parties assume it was processed |
| Business Reconciliation | Data discrepancies that didn't clearly fail are uncovered | A monthly report reveals a gap whose origin is hard to trace |

Each layer depends on the one before it. Retries without Idempotency create duplicates. A Dead Letter without Reconciliation masks that even "technically successful" messages didn't necessarily reflect the correct business state.

## Idempotency: The Key to Preventing Duplicates

Any integration that can receive the same message more than once—and almost all integrations fall into this category—requires an External ID that uniquely identifies the *event*, not just the record. In Salesforce, the common implementation is an Upsert based on an External ID field with a unique constraint, combined with a logging table (Custom Object or Platform Event Log) that records which event identifiers have been fully processed.

Common mistake: relying solely on an Upsert to the business record itself (e.g., Order External ID) without documenting intermediate steps. If the process also involves updating inventory in an external system, an Upsert on the order doesn't prevent a duplicate call to update inventory. Every sub-operation with an external side effect needs to be idempotent *itself*, not just the final record.

## Retry: Backoff Policy and Error Classification

Not every error warrants a retry. It's crucial to distinguish between three categories upfront:

- **Temporary errors** (Timeout, 503, Rate Limit) - Candidates for Exponential Backoff retries, meaning the interval between attempts increases (e.g., 30 sec, 2 min, 10 min) to avoid exacerbating system load.
- **Structural errors** (missing required field, validation rule violation, invalid value) - Should not be retried, as they will fail again in the same way. They should go directly to a Dead Letter Queue.
- **Authorization or configuration errors** (expired token, API Version change) - Require immediate alerts to a technical team, as they block the entire queue, not just a single message.

In Salesforce, retries are typically implemented at the middleware layer or within Apex Queueable/Batch jobs, with a retry counter stored on the record itself. A reasonable number of attempts for most cases is 3-5 with backoff, not infinite retries—unlimited retries turn a temporary glitch into sustained load on both systems.

## Dead Letter Queue: Where Failed Messages "Live"

A Dead Letter Queue isn't just storage—it's a contract. Every message reaching it should include: the original event identifier, the full payload, a classified failure reason, the number of attempts made, and the time it entered the queue. Without this information, "handling" a Dead Letter becomes guesswork.

Two common implementation approaches in Salesforce:

1. **Dedicated Custom Object** (`Integration_Failed_Message__c`) with structured fields and List Views by error type—suitable when business teams need visibility within Salesforce itself.
2. **External queue at the middleware layer** (e.g., Dead Letter Exchange in MuleSoft/Boomi)—suitable when the technical team monitors outside Salesforce and wants to avoid burdening the Salesforce org.

The choice depends on who is expected to act on the failure: if it's a business process owner, they need to see it within Salesforce; if it's a technical integration team, an external layer is often preferable.

## Business Reconciliation: The Check That Uncovers What Retries Missed

Even with perfect Idempotency and Retries, some failures "succeed" technically but create a business discrepancy—for example, a message received and processed, but with an incorrect value from outdated source data. Reconciliation is a periodic process (daily, hourly, depending on event volume) that compares counts or aggregate sums between two systems—for instance, the number of orders created in the ERP versus the number of orders created in Salesforce for the same day—highlighting discrepancies before they escalate into customer service issues.

A good Reconciliation process doesn't require field-by-field checking of every record; a checksum or aggregate count is sufficient to signal when deeper investigation is needed. In most organizations, daily frequency is adequate; for financial or critical processes (orders, invoices), checks within a few hours are necessary.

## Decision Framework: When Each Layer is Mandatory, and When It's Optional

| Criterion | Idempotency required | Automatic Retry required | Separate Dead Letter required | Daily Reconciliation required |
| --- | --- | --- | --- | --- |
| Event generates financial transactions or inventory movement | Yes | Yes | Yes | Yes |
| Event is one-way, read-only | Not critical | Yes | No | No |
| Volume over 500 messages per day | Yes | Yes | Yes | Recommended |
| External partner without high availability SLA | Yes | Yes, with long Backoff | Yes | Recommended |
| Integration between two non-financial, low-volume objects | Recommended | Recommended | Not essential | No |

The guiding principle for this table: the more a failure has financial or irreversible consequences (shipping, billing, inventory update), the more all four layers shift from "recommended" to "mandatory"—regardless of volume.

## Example Scenario: Retailer with Two-Way Order Synchronization

A retail company with 40 branches uses Salesforce for B2B order management and an external ERP for inventory and invoicing. The integration was initially built with a simple REST call: when an order is created in Salesforce, a synchronous call creates it in the ERP. No retry, no Dead Letter.

During peak season (Black Friday), the ERP began returning timeouts for approximately 3% of calls. Without a retry mechanism, these 3% simply "vanished"—the order remained in Salesforce with a "sent" status, but the ERP had no knowledge of it. Within two days, about 140 orders accumulated that never reached the packing process, discovered only when customers called to inquire about their goods.

The solution implemented afterward: an Apex Queueable layer that retries up to 5 times with a backoff of 1/5/15/30/60 minutes; an `ERP_Sync_Status__c` field with values Pending/Synced/Failed; a `Integration_Failed_Message__c` Custom Object to consolidate final failures with a "Retry" button for the operations team; and a daily Reconciliation report that compares order counts between the systems and sends a Slack Alert when the discrepancy exceeds zero. The detection time for similar issues decreased from two days to less than an hour.

## Common Risks and Preventive Actions

| Risk | How it manifests | Preventive action |
| --- | --- | --- |
| Infinite retries on a structural error | The same message repeatedly fails, creating load | Classify errors upfront and send structural errors directly to Dead Letter |
| Lack of unique event identifier | Retry or duplicate call creates a duplicate record | External ID on the event, not just the final record |
| Dead Letter without an Owner | Messages pile up and no one addresses them | Assign an Owner and define SLA for resolution by event type, not system |
| Technical monitoring only (API status) | Integration is "green" but business data is inconsistent | Add Reconciliation comparing business outcomes, not just response codes |
| Fixed and too-short Backoff | Repeated attempts exacerbate load during widespread issues | Exponential Backoff with a defined maximum number of attempts |

## Checklist Before Approving Error Handling Design

- ☐ Every event has a unique identifier (External ID) to prevent duplicates on retry.
- ☐ Errors are pre-classified as temporary/structural/authorization, with different handling for each type.
- ☐ Backoff policy is defined with a maximum number of attempts.
- ☐ An accessible Dead Letter Queue exists with full payload and failure reason.
- ☐ An Owner and defined SLA for resolution are established for each error type.
- ☐ A periodic Reconciliation process compares business outcomes between systems.
- ☐ Alerts are sent to a channel where someone actively reads them (not just logs).
- ☐ Test scenarios include service interruption of the secondary system, not just happy path.

## How This Connects to the Rest of the Architecture

Error handling design doesn't stand alone—it relies on the data and permission layers defined in the [CRM Architecture Guide](/en/insights/crm-architecture-guide), and on the decision of whether logic is implemented in Flow or Apex according to [Salesforce Flow vs. Apex](/en/insights/salesforce-flow-vs-apex). The permission model through which integration components write data must be evaluated against the [Salesforce Permission Model](/en/insights/salesforce-permission-model) to ensure the technical integration user doesn't have overly broad access. And as message volume grows, the question of retries directly intersects with API limits detailed in [Salesforce API Limits](/en/insights/salesforce-api-limits-resilience).

## Summary

Integration error handling isn't a feature you add at the end—it's the difference between a system that breaks and is discovered after a customer complains, and one that flags issues before damage accrues. The four layers—Idempotency, classified Retries, a Dead Letter with an Owner, and Business Reconciliation—don't require a separate project, but they do demand explicit decisions during the planning phase, before the first integration goes live. An organization that self-alerts to 3% of messages failing within an hour is fundamentally different from one that discovers it from an angry customer.

### Questions and answers
**What's the difference between automatic Retry and a Dead Letter Queue?**
A Retry mechanism attempts to re-execute a failed call for transient reasons – like a timeout, row lock, or rate limit – according to a defined backoff policy. When retry attempts are exhausted, or the error is classified as non-recoverable (e.g., a missing mandatory field), the message is moved to a Dead Letter Queue. This queue holds the message for separate manual or automated handling, preventing it from blocking the rest of the queue.

**How do you maintain Idempotency when an external system sends the same message twice?**
You need an external unique key (External ID) that identifies the event, not just the record, and a pre-creation check – an Upsert based on that key. If the event involves financial transactions or inventory changes, a separate logging table is required to record which event IDs have already been processed. This prevents duplicate runs from creating duplicate entries or actions.

**How long can a failed message remain in a Dead Letter Queue before it becomes a business problem?**
There's no universal answer; it depends on the process. An order not synced within an hour could lead to duplicate delivery; a contact detail update might wait a day. The practical rule is to define an SLA for handling based on the event type, not the system type. Ensure this SLA translates into real alerts, not just a log entry.

**Who is responsible for a stuck message – the Salesforce team or the other system's team?**
Operational responsibility should lie with whoever owns the integration layer, not solely with one of the two systems. If there's no dedicated integration layer and messages are point-to-point, set up a pre-defined escalation matrix: which error types go to the Salesforce team, which to the external API owner, and who decides if clarity is lacking within a specific timeframe.

**Does Middleware automatically solve error handling challenges?**
No. Middleware tools (such as MuleSoft, Boomi, or other iPaaS platforms) provide the infrastructure for Retry, Queues, and monitoring. However, your organization still needs to define the backoff policies, error classification, and business reconciliation strategy. A tool without a defined policy will simply generate a detailed log of failures that no one ever resolves.

---

## Technical Debt in Salesforce Flows & Apex: Identify, Measure, & Resolve Without Halting Development
URL: https://hpi.pro/en/insights/salesforce-flow-apex-technical-debt
Technical debt in Salesforce automations isn't a result of one bad choice between Flow and Apex. It accumulates from hundreds of micro-decisions made without clear policies or a holistic architectural view. This article reveals how to concretely identify it—using data, not gut feelings—and how to build a reduction plan that maintains your development velocity.

## Why Technical Debt in Automations Differs from Regular Technical Debt

In Salesforce, acquiring technical debt is easier than in a typical development environment because the platform allows anyone to add automation without following a structured code process. Every Admin who adds a Flow Before Save to fix an immediate problem, every Trigger someone added two years ago for reasons no one remembers, and every formula field with a dependency on another field that no longer exists—all these accumulate into a layer that no one sees in its entirety.

The fundamental difference between regular technical debt and technical debt in Salesforce automations is that the latter almost always lacks central documentation. Code resides in a Repository with commit history; a Flow resides in Setup without an explanation of why it was created. This makes the identification phase particularly difficult—not because the problem is technically complex, but because there's no one to ask.

This article discusses identifying, measuring, and reducing this debt. It does not address the question of when to choose Flow versus Apex in the first place—that topic is covered in [Flow vs. Apex: How to Choose](/en/insights/salesforce-flow-vs-apex).

## Three Types of Debt That Behave Differently

Not all technical debt is the same, and treating it all as a single problem leads to wasted effort. It's helpful to separate it into three categories:

| Debt Type | Typical Example | What Happens if Ignored | Resolution Priority |
| --- | --- | --- | --- |
| Structural Debt | Multiple Triggers on the same object without a unifying Framework | Unpredictable execution order, silent failure | High |
| Logical Debt | Flow with dozens of decision branches representing a business rule that has since changed | Incorrect decisions running silently | High |
| Maintenance Debt | Fields, Flows, and custom settings without documentation or use | Extended development time, fear of touching | Medium |

Structural and logical debt pose real operational risks—they can lead to incorrect data reaching a customer or a financial report. Maintenance debt slows down the team but doesn't necessarily break a process. This division dictates the order of resolution: eliminate operational risk first, then improve development speed.

## How to Identify Debt Before It Explodes in Production

Identification shouldn't start with an exhaustive manual code review—that's too expensive and unsustainable. It begins with several quantitative metrics that can be extracted within an hour:

- **Number of active Flows on each core object** (Lead, Opportunity, Case, etc.). Beyond five to six active Flows on the same object, the execution order becomes difficult to predict.
- **Number of Triggers not unified under a single Framework** per object. More than one Trigger per object is already a warning sign, unless an explicit routing layer exists.
- **Density of SOQL queries within loops** appearing in logs as near-threshold Governor Limits, even if not actually hit.
- **Unusual runtime for a Flow or Apex Batch** that increases over time without a proportional increase in business volume.
- **Fields and variables with no identified use** in a Field Usage report, kept "just in case someone needs them."

These metrics don't definitively prove a problem but provide a targeted list of suspects. Combining them with an understanding of the depth of integrations that automation depends on is detailed in [Salesforce Integration Patterns](/en/insights/salesforce-integration-patterns).

## Decision Framework: What to Tackle First

Not every finding on the suspect list warrants the same investment. A simple framework for prioritization is based on two axes—business impact and probability of failure:

| Scenario | Business Impact if Failed | Probability of Short-Term Failure | Action |
| --- | --- | --- | --- |
| Automation on an order/billing process with multiple, undocumented Triggers | High | High | Immediate refactor, outside regular queue |
| Complex Flow on an internal status update with no external impact | Low | High | Document and simplify at a regular pace |
| Old Trigger that works stably but whose purpose is unclear | Potentially high | Low | Document first, no immediate touch |
| Unused fields and orphaned custom settings | Low | Low | Periodic cleanup at the Release level |

The guiding principle: don't address what's most annoying to developers, but what's most dangerous to the business. An old, stable Trigger that no one understands is sometimes the most tempting case to touch first—and that's exactly where an incautious touch causes the most damage.

## Organizational Scenario: An Insurance Company with 14 Flows on Opportunity

Imagine a medium-sized insurance company that has been managing B2B sales through Salesforce for six years. Over time, 14 active Flows accumulated on the Opportunity object: seven handle stage updates, three send internal notifications, two synchronize data to an external BI tool, and two others are remnants of an old process that was replaced two years ago but never deactivated.

The trigger for identifying the problem was a specific issue: a deal moved to "Closed-Won," but the notification to the underwriting team wasn't sent because another Flow updated the same field concurrently, creating an unanticipated execution timing. The team spent two days trying to understand why—not because the bug was complex, but because no one knew the full execution order of the 14 components.

The solution wasn't "rewrite everything in Apex." The team first mapped all 14 Flows and classified them according to the table above: the two old Flows were deactivated after verifying no active dependency, the three notifications were combined into one Flow with clear routing logic, and the seven stage updates were unified under a single Record-Triggered Flow with an explicit execution order. Result: from 14 components to 6, with documentation of the execution order that any new developer can read in 15 minutes.

## Risks in the Reduction Process Itself

Reducing technical debt is an inherently risky activity, not just a fix for existing risk:

| Risk | How it Appears in Practice | Prevention Action |
| --- | --- | --- |
| Changing execution order breaks a hidden dependency | A process that worked stops working after Flow consolidation | Full dependency mapping and regression testing before each consolidation |
| Deleting a "dead" component that actually still runs in a rare scenario | An issue appearing only at quarter-end or in seasonal edge cases | Review execution logs for a full year, not just the last month |
| Converting to Apex without a process owner who understands the business rule | The new code is "technically correct" but implements an old rule that has changed | Validate business rule with process owner before writing code, not just against existing code |
| Refactor done in one Sandbox and not synchronized | The problem reappears in production after the next Deploy | Manage the change through a regular Release process, not as an "out-of-band" fix |

The common risk for all is the same phenomenon: the team believes they are "just cleaning up" and therefore skips tests they would perform for a new feature. At the Governance level, a refactor should undergo the same acceptance process as regular development—no less.

## Metrics for Ongoing Debt Reduction Monitoring

To confirm that the effort is truly reducing debt and not just moving it around, it's advisable to track:

- **Number of active automation components per object**, as a quarterly trend rather than a single data point.
- **Average time to diagnose an automation issue**, from report to identification of the responsible component.
- **Percentage of documented components** out of all active automations in the core cluster.
- **Number of recurring issues on the same component** within a three-month period.

Organizations struggling to prioritize between refactoring and ongoing development use [CRM Architecture services](/en/crm-architecture) to build a binding and measurable work plan.

## Operational Checklist Before Starting a Refactor

- ☐ A complete map of all active automations on the relevant object exists.
- ☐ The actual execution order is known, not just the creation order.
- ☐ Every component slated for removal has been checked against a full year of execution logs.
- ☐ The business process owner has confirmed the rule being reimplemented.
- ☐ A testing environment that simulates real data volume exists.
- ☐ A "before and after" metric for the number of components and diagnosis time has been defined.
- ☐ The refactor process follows a regular Release, not an exceptional Deploy.
- ☐ Consistent capacity has been allocated in each Sprint for ongoing maintenance, not just a one-off event.

## Conclusion

Technical debt in Salesforce automations builds up silently, one component at a time, and therefore it should also be dismantled silently—not in a major cleanup project that halts development for a month. The necessary tools are relatively simple: counting components by object, mapping execution order, and classifying by business impact versus probability of failure. What determines success is continuity—allocating consistent capacity for debt reduction alongside ongoing development, rather than reactively chasing the component that caused the last issue. An organization that adopts such a measurement habit reaches a state where any new developer can understand within an hour what happens when a record is saved—and that, ultimately, is the most practical definition of being free from technical debt.

### Questions and answers
**How many Flows on a single object is considered too many?**
There's no magic number, but there's a clear indicator: If a developer can't predict what will happen when a record is saved without opening every Flow and tracing the execution order, you already have an operational problem—even if it's only three Flows. The issue isn't the quantity, but the lack of coordination and documented execution order between them.

**Can technical debt be reduced without pausing new feature development?**
Yes, and this is often the most effective approach. Allocate a fixed percentage of each Sprint—for example, one-tenth of the capacity—to technical debt reduction based on a priority list. This is more sustainable than dedicated 'freeze Sprints' which are almost always deferred when business priorities demand attention.

**When should a Flow be converted to Apex code due to technical debt?**
Consider converting when a Flow contains overly complex logic with more than a few decision branches, when it repeatedly queries the same data due to poor modular design, or when it requires robust automated testing that graphical tools don't adequately support. The conversion itself is a technical tool; the decision should stem from measuring actual complexity, not stylistic preference.

**How can technical debt be measured without purchasing external tools?**
Start with Salesforce Optimizer and internal Setup Reports to count active Flows by object, along with Tooling API queries for Apex limits and Debug Logs for exceptional run times. While not a full substitute for dedicated Static Analysis tools, this is sufficient to build an initial priority list for refactoring.

**What do you do when development teams resist allocating time for refactoring?**
Frame the cost in terms that management understands: recurring support hours for the same issues, extended release cycles, and concrete risks to critical business processes. Refactoring presented as 'code cleanup' is almost always deprioritized; refactoring presented as operational risk mitigation is prioritized.

---

## Salesforce Data Model: Standard vs. Custom Objects & Key Decisions
URL: https://hpi.pro/en/insights/salesforce-data-model-design
Your data model is the most expensive decision to change after go-live. This guide covers when to stick with Standard Objects, when Custom Objects are justified, choosing between Lookup and Master-Detail, and how a seemingly clean model built in a workshop can create reporting, permissions, and performance limitations years down the line.

## The Short Answer

A good Salesforce data model isn't necessarily the most theoretically elegant. Instead, it's one that effectively balances three elements simultaneously: the business process, the permissions model, and the required reporting. Most failing models are built with only the first element in mind.

The big difference between a data model decision and other project decisions is the cost of change. Modifying a Flow might take a day; changing the relationship type between objects after two years of data, automations, and integrations is a project in itself. This is why upfront planning investment pays off more here than anywhere else.

## The First Rule: Start with Standard Objects

Account, Contact, Lead, Opportunity, Case, and Product come with capabilities that aren't freely available with custom objects. These include sales processes, Forecasting, Entitlements, Omni-Channel, mobile app functionality, and built-in integration with other products on the platform.

An organization that creates `Customer__c` instead of using Account will initially have a seemingly cleaner model. However, they'll later discover that every out-of-the-box capability requires custom development. The rule of thumb: deviate from standard only when there's a reason you can state in a single sentence.

## When a Custom Object is Necessary

| Scenario | Custom Object? | Justification |
| --- | --- | --- |
| Contract/Subscription with its own lifecycle | Yes | Separate statuses, renewal, ownership, and reporting |
| Installed asset at a customer site | Yes (or standard Asset) | Independent entity with service history |
| Additional "potential customer" | No | This is a Lead or an Account with a Record Type |
| Department within the organization | No | Data about a user, not an entity |
| Complex pricing line items | Depends | Review Quote Line or CPQ before custom building |

## Normalization vs. Denormalization: The Reporting Impact

In classical databases, normalization is a virtue. In Salesforce, it's traded against reporting convenience. Each additional relationship level makes building reports difficult without external tools, as standard reporting has limited depth in relationships.

The common compromise is to normalize where data changes and is duplicated, and to selectively denormalize frequently queried fields onto the object used for reporting – provided the duplication is managed automatically, not manually. A duplicated field updated manually will become stale within months.

## Permissions Are Part of the Model, Not an Afterthought

The question "who sees what" should be asked when sketching out objects. A model where sensitive data resides on the same object as operational data will later force workarounds – shadow objects, encrypted fields, or opening up overly broad visibility.

The practical test: for every new object, write one line – who owns it, who reads it, who modifies it, and what happens in the hierarchy. If the answer requires more than four lines, the structure likely conflates two entities.

Further details on information sources and update authority can be found in [Source of Truth in an Organization](/en/insights/salesforce-source-of-truth), and on managing core entities in [Master Data Management](/en/insights/salesforce-master-data-management).

## Scenario: A Software Company that Modeled Around Departments

A medium-sized SaaS company built a model with four custom objects – one for each sales team – because each team had a different process. A year and a half later, teams merged, requiring: report unification, parallel automations in four places, and an internal migration of 60,000 records between objects.

The rebuild centered around a single Opportunity object with Record Types for the different processes. The same business distinctions were preserved – different sales paths, different fields, different Page Layouts – but at the configuration level, not the structural level. The next organizational change will require a Record Type change, not a migration.

The rule that emerged: structure represents entities; configuration represents organizations. What's expected to change every couple of years shouldn't reside in the structure.

## Performance and Volume – What Really Matters

Data model performance issues primarily stem from three areas: Data Skew (a single parent with tens of thousands of children, like an "Individual Customers" Account), nested formulas that calculate in real-time across relationships, and large-scale Apex Sharing. All three can be identified during the planning phase by asking how many records are expected under each parent.

## Common Risks and Preventive Actions

| Risk | How it appears in practice | Preventive Action |
| --- | --- | --- |
| Unnecessary Custom Object | Out-of-the-box features are manually rebuilt | Check Standard Objects before any new custom object |
| Master-Detail too early | Cascading deletes and an unchangeable structure | Start with Lookup if roll-up isn't needed |
| Model reflecting organization | Every organizational change becomes a migration | Use Record Types instead of objects |
| Data Skew | Locks and slowness during mass updates | Distribute parent records, test volume in planning |
| Permissions as an afterthought | Workarounds and overly broad visibility | Access matrix for each object during planning |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Field Usage | Fill rate for each field | Quarterly |
| Reporting | Percentage of reports requiring manual consolidation | Quarterly |
| Structure Stability | Number of structural changes per half-year | Semi-annually |
| Performance | Mass update times and locks | Monthly |

Data model planning as part of overall architecture is performed as part of [Integrations and Data Services](/en/integrations-data).

## Checklist Before Freezing the Model

- ☐ Each custom object has a one-sentence justification
- ☐ Alternative Standard Objects were checked for each entity
- ☐ Relationship type was explicitly chosen with a justification for Master-Detail
- ☐ Expected volume for each parent was estimated (Skew check)
- ☐ Access matrix: owner, reader, modifier, hierarchy
- ☐ Confirmed all key reports can be built with the model
- ☐ Duplicated fields are updated automatically only
- ☐ Anticipated organizational changes are handled via configuration
- ☐ Up-to-date and documented ERD exists
- ☐ Defined who approves future structural changes

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**When is a Custom Object justified, and when is it a mistake?**
A Custom Object is justified when the entity has its own lifecycle—distinct statuses, ownership, permissions, and reporting needs. It's a mistake when created solely to avoid adding more fields to an existing object or merely to mirror an organizational structure. Organizational structures evolve; objects don't easily adapt to those changes.

**Should I use a Lookup or Master-Detail relationship?**
Master-Detail provides Roll-Up Summaries and inherited security, but it's rigid: deleting the parent deletes the children, and a child record cannot exist without a parent. Lookup is more flexible and can be modified later. The practical rule: use Master-Detail only when the child is truly meaningless without the parent AND automatic summarization is required.

**How many fields are too many on an object?**
The number is less critical than the consumer. An object with 200 fields, all used in reports, is fine. An object with 60 fields where most are empty in 80% of records indicates entities crammed into one place. The best check is the fill rate for each field, not just a count.

**Should I mirror my ERP structure in Salesforce?**
No. ERPs are designed around transactions, while Salesforce is built around relationships and business processes. Full mirroring creates dozens of objects that no one uses. Only transfer what's essential for your sales and service processes to Salesforce, and for everything else, utilize remote access or a Data 360 strategy.

**How do you know the data model won't hold up?**
Three early warning signs: reports requiring manual consolidation across objects, deeply nested formula fields to bridge structural gaps, and permission requests that can't be fulfilled without broad visibility. Each indicates that the structure doesn't align with the underlying business process.

---

## Salesforce Master Data Management: Ownership, Golden Records, and Sync Strategies
URL: https://hpi.pro/en/insights/salesforce-master-data-management
MDM falters when seen purely as a tech project, but thrives as an ownership discipline. This guide reveals which entities truly need master management, how to build a 'Golden Record' between CRM and ERP without disrupting systems, when a dedicated MDM tool is essential versus when Salesforce suffices, and how to measure the effectiveness of your data governance.

## The Short Answer

Master Data Management isn't a database; it’s an agreement. This agreement defines who establishes an entity, who is authorized to modify it, how two records are identified as the same entity, and what happens when systems disagree. Technology merely enforces what has been agreed upon.

The common pitfall is starting by selecting a tool. An organization that hasn't clarified what defines a "customer" will end up with a tool that consolidates the exact same ambiguity, just faster and at a higher cost.

## What Belongs in Master Data and What Doesn't

| Data Type | Example | Is it Master Data? |
| --- | --- | --- |
| Master Data | Customer, Product, Vendor, Site | Yes |
| Reference Data | Countries, Currencies, Industry Codes | Separate, simpler management |
| Transactional | Order, Invoice, Case | No |
| Analytical | Segmentation, Scoring, Forecast | No - Derived |

This distinction is crucial because each type requires a different governance approach. Reference Data is managed in a small table with a single owner; Transactional Data remains in its originating system; Analytical Data must not become a source of truth, as it's a product of changing calculations.

## Three Implementation Styles

**Registry** - Manages only an identifier table that links records across different systems. It’s inexpensive, fast, doesn’t alter any existing systems, and provides a unified view for reading. This is almost always suitable as a first step.

**Consolidation** - Creates a Golden Record for reporting and analysis purposes, without flowing it back to source systems. Suitable when the primary pain point is fragmented reporting.

**Centralized** - The Master Data becomes the authoritative source, and all systems consume from it. This offers the highest value but also demands the highest level of governance and approval processes. Organizations that jump straight to this often discover they lack the Stewards to operate it effectively.

The practical approach is a ladder: start with a Registry for one entity, then expand – based on proven value rather than a master plan.

## Survivorship: The Rules That Determine What Survives

The core of the Golden Record lies in field-level Survivorship rules: each field has a preferred source and a backup rule for when the preferred source is empty. Alongside this, source system identifiers are always retained, allowing every value to be explained.

A principle that avoids arguments: A Golden Record neither deletes source records nor claims to replace them. It's a layer that points to them. This means you can correct a rule and recalculate – a capability unavailable to those who merge everything at the loading stage.

Further depth on ownership determination can be found in [Source of Truth in an Organization](/en/insights/salesforce-source-of-truth) and the preceding deduplication process in [Salesforce Data Deduplication](/en/insights/salesforce-data-deduplication).

## Stewardship: The Role That Determines Success

Any MDM governance model generates a decision queue: matches the system is unsure about, requests to create new entities, and contradictions between sources. If there's no person with dedicated time to clear this queue, it grows until it's ignored.

A realistic scope: In a mid-sized organization, this means a few dedicated hours per week for one entity, often allocated to someone from the business side rather than IT. This investment determines whether MDM truly thrives or becomes silent infrastructure.

## Scenario: Manufacturer with Three Systems and One Customer

An industrial manufacturer managed customers in three places: ERP, Salesforce, and a service system. The same corporation appeared as three distinct entities, and a "revenue per customer" report was manually built in Excel quarterly.

Instead of a full MDM project, the organization began with a Registry: an identifier table was built in Data 360, linking the three records using a tax ID and a secondary key, and only then was a read-only Golden Record constructed. Salesforce didn't change its structure; it received a global identifier field and a "all activity for this group" view.

The outcome after a quarter: The manual report was eliminated, and for the first time, sales representatives saw credit exposure at a group level – which prompted a single pricing decision that recouped the cost of the phase. Expansion to a Centralized model was considered only after it was proven that a Steward was actively clearing the queue.

## Common Risks and Preventive Actions

| Risk | How It Manifests in Practice | Preventive Action |
| --- | --- | --- |
| Starting with a tool | A unified repository reflecting existing ambiguity | Define entity and ownership before tool selection |
| Too many entities | A long project with no visible value | One entity to production, then expand |
| No Steward | A matching queue that grows and is abandoned | Appoint a role with dedicated time and an SLA |
| Destructive merging | Unable to explain or restore a value | Retain source identifiers and allow recalculation |
| Premature Centralized | All systems dependent on immature infrastructure | Start with a Registry |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Coverage | Percentage of records linked to a global identifier | Monthly |
| Accuracy | Rate of links revoked or corrected | Monthly |
| Stewardship Queue | Open items and average closing time | Weekly |
| Business Value | Manual reports eliminated, group-level decisions enabled | Quarterly |

Building a tiered MDM framework is performed within [Integrations and Data Services](/en/integrations-data).

## MDM Pre-Initiation Checklist

- ☐ Up to three entities selected for the first wave
- ☐ A written business definition exists for each entity
- ☐ Implementation style chosen: Registry, Consolidation, or Centralized
- ☐ Strong identification keys located for each source
- ☐ Survivorship rules written at the field level
- ☐ Source identifiers retained, allowing recalculation
- ☐ A Steward designated with dedicated time and an SLA
- ☐ An approval process defined for new entity creation
- ☐ One value metric determined for the first wave
- ☐ A decision made on when to even consider a dedicated tool

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data

### Questions and answers
**Which data entities truly require Master Data Management?**
Focus on entities that appear in multiple systems and directly impact revenue, regulatory compliance, or customer experience. For most organizations, this means three to five core entities: Customer/Vendor, Product, Sales/Organizational Structure, and sometimes Site or Asset. Attempting to manage 20 entities simultaneously is a fast track to project stagnation.

**Is a dedicated MDM tool always necessary?**
Not always. For up to three source systems and moderate matching complexity, Salesforce with External IDs, Matching Rules, and managed integrations can be sufficient. A specialized MDM tool is justified with numerous data sources, formal data stewardship requirements, historical data retention for compliance, or complex field-level survivorship rules.

**What's the difference between Registry, Consolidation, and Centralized MDM?**
Registry only stores identifier mappings, leaving the data in its source system. Consolidation creates a unified copy purely for reporting and analytics. Centralized transforms the master data store into the authoritative source that all systems read from. As you move up this scale, the value increases, as do the implementation and governance costs.

**Can Salesforce be the Master for Customer data?**
Yes, especially if the customer originates and is primarily managed within the sales process. In many organizations, the practical compromise is a split: legal identity and commercial terms reside in the ERP, while sales entity and contact details are managed in Salesforce, with a shared identifier linking the two.

**How long does it take to see initial value from MDM?**
For a single entity across two source systems, expect six to twelve weeks to achieve a live, production-ready 'Golden Record'. MDM projects planned for two years to build 'full infrastructure' often don't survive executive leadership changes. One entity in production is far more valuable than a perfect architecture in a presentation deck.

---

## Data 360 vs. Salesforce CRM Data: Where Should Everything Live?
URL: https://hpi.pro/en/insights/data-360-vs-crm-data
Not all customer data belongs in your CRM. This guide distinguishes between operational data driving daily processes and high-volume behavioral data used for profile unification, segmentation, and activation. Learn how these decisions impact performance, cost, permissions, and future AI capabilities.

## The Short Answer

The decision between CRM and Data 360 isn't about "where there's space" but "who consumes the data and at what rate." CRM is structured around a record that someone opens, edits, and advances through a process. Data 360 is built around a stream of events unified into a profile, used for segmentation, analysis, and activation.

When you mix the two, you get one of two outcomes: a cumbersome CRM with millions of untouched records, or a rich data layer that no one acts upon because it doesn't reach the workflow.

## Practical Division

| Information Type | Where | Rationale |
| --- | --- | --- |
| Customer, Contact, Opportunity, Case | CRM | Manually managed, drives process and permissions |
| Sales stage, Tasks, Approvals | CRM | Automation and daily operations |
| Clicks, Views, Product Usage | Data 360 | High volume, not manually managed |
| Transaction History from ERP | Data 360 (or virtual access) | Volume, and external source of truth |
| Unified Profile and Cross-System Identity | Data 360 | Unifies identifiers |
| Scoring, Segmentation, Recommendation | Calculated in Data 360, displayed in CRM | High-volume calculation, workflow utilization |

The last row presents the core principle: calculate where there's volume, display where decisions are made.

## The Four-Question Test

Before adding data to CRM, ask: Does someone manually edit it? Do automation or Validation rules rely on it? Is it required in a routine operational report? Does it affect permissions or ownership? If the answer to all four is no, the data almost always belongs in the unification layer.

The inverse also holds: Data stored only in Data 360 but required for real-time decision-making must have a feedback mechanism – a summary field, a display, or an action – otherwise, it won't impact business outcomes.

## Volume, Performance, and Cost

CRM is priced and designed around business records. Inserting behavioral events changes the load profile: mass updates slow down, report building becomes heavy, and backups and test environments grow. Data 360 is designed for this pace and priced by consumption — which requires different attention: broad queries and unnecessary flows generate ongoing costs.

In both cases, the hygiene is the same: transfer only what has a consumer, and define Retention for each stream. The discussion of copying versus remote access is detailed in [Zero Copy and Federation](/en/insights/data-360-zero-copy-federation).

## Permissions: The Easily Missed Gap

CRM's permission model is rich and precise at the record and field level. A unification layer operates differently — it's built for analysis, and its exposure is governed by access rules and masks. An organization that moves sensitive data to the unification layer without planning for it can create broader visibility than what exists in CRM.

The rule: Any stream containing sensitive information receives an explicit exposure decision *before* streaming, not after.

## Scenario: A Retailer Moved Everything to CRM

A retail chain moved three years of purchase history — about 40 million rows — to a custom object in CRM, intending for "the salesperson to have a complete picture." The result: long load times on the customer screen, nightly updates that ran over the window, and reports that timed out.

In the rebuild, only four derived values remained in CRM: last purchase date, 12-month value, top category, and churn risk flag. The full history moved to the unification layer, with a link for on-demand detailed viewing.

The customer screen loaded quickly, salespeople got what they truly needed to ask about, and marketing segmentation actually improved — because it ran on data all in one place, not just what managed to get into CRM.

## Common Risks and Prevention Actions

| Risk | How it appears in practice | Prevention Action |
| --- | --- | --- |
| Everything in CRM | Performance, cost, and load times | Derived values instead of raw history |
| Everything in the unification layer | Insights don't reach the workflow | Feedback mechanism: field, display, or action |
| No Retention | Volume grows without ownership | Retention policy for each stream |
| Unplanned permissions | Sensitive data exposure in analysis | Exposure decision before streaming |
| Ununified identity | Fragmented profile for the same customer | Defined Identity Resolution rules |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Performance | Customer screen load time and mass updates | Monthly |
| Unification | Percentage of successfully unified profiles | Monthly |
| Activation | Actual segments and actions generated from data | Quarterly |
| Cost | Consumption vs. budget per stream | Monthly |

Planning the division between CRM and the unification layer is performed as part of [Integration & Data Services](/en/integrations-data).

## Decision Checklist

- ☐ Map data streams by volume and update rate
- ☐ Complete the four-question test for each stream
- ☐ Define derived values to be displayed in CRM
- ☐ Establish a feedback mechanism from unification to workflow
- ☐ Document Identity Resolution rules
- ☐ Make an exposure decision for each sensitive data stream
- ☐ Implement a Retention policy for each stream
- ☐ Estimate initial-wave consumption cost
- ☐ Select one Use Case for proof of value
- ☐ Assign ownership for each data stream

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**What's the key question to determine where data should live?**
Does a user or automation directly act on this data within a workflow? If yes, it belongs in your CRM. If it's intended for segmentation, analysis, profile unification, or model input, it belongs in Data 360. Data that no one acts upon or analyzes likely doesn't belong in either.

**Does Data 360 replace a Data Warehouse?**
Not necessarily. Data 360 specializes in unifying customer profiles and activating them back into sales, service, and marketing processes. An enterprise Data Warehouse continues to serve broad financial and operational reporting. In practice, they often coexist, sometimes connected via virtual access without replication.

**Is Data 360 essential for AI?**
Not for every use case. For summarizing conversations or drafting responses, CRM context might suffice. However, for recommendations, scoring, or an AI Agent requiring extensive history from multiple systems, a unified layer is crucial—and that's precisely the role of Data 360.

**What happens when behavioral data is copied into CRM?**
You start paying twice: in storage and performance. Millions of event rows on custom objects slow down bulk updates, inflate indexes, and complicate reporting. The typical solution is summarization: store a derived value in CRM—like a score, last-activity date, or counter—rather than the raw events themselves.

**Where do we start when our CRM is already overloaded?**
Begin by identifying three high-volume, low-operational-use data sets. Extract them to a unification layer, leaving a summarized field in the CRM. This improves performance and provides a foundation for segmentation without a full infrastructure overhaul.

---

## Zero Copy and Data Federation in Data 360: When to Avoid Data Duplication
URL: https://hpi.pro/en/insights/data-360-zero-copy-federation
Any data replication introduces commitments: pipeline overhead, increased costs, potential discrepancies, and elevated risks. Zero Copy allows you to access data where it resides, but it's not a universal solution. This guide clarifies when a virtualized approach is superior, when data ingestion is more appropriate, and how to make decisions based on freshness, performance, governance, and data transfer costs.

## The Short Answer

The old rule was, "to analyze data, first copy it." Zero Copy eliminates this assumption in many cases: you can query a table residing in an external data warehouse without moving it. This is a real capability, but it trades one type of cost for another. Instead of storage and pipeline costs, you incur computational costs and dependency on source availability.

The decision is correct when treated like any architectural decision: based on usage requirements, not on trends.

## Four Decisive Parameters

| Parameter | Leans Towards Zero Copy | Leans Towards Ingestion |
| --- | --- | --- |
| Freshness | Requires the absolute latest data always | Scheduled batches are sufficient |
| Performance | Analysis and segmentation, tolerance for seconds | Real-time operations, consistent response time |
| Volume and Frequency | Large volume, few queries | Medium volume, many queries |
| Governance | Source maintains strong policies | Full control over the copy is required |

This table also explains why most organizations arrive at a hybrid approach: operational streams are ingested, while heavy analytical streams remain in place.

## Responsibilities Remaining for the Team Even with Zero Copy

Virtual access eliminates the pipeline, not the work. You still need: schema mapping to the common model, deciding on identification keys for profile unification, handling schema changes at the source, and monitoring availability. Renaming a column in the external warehouse will break a virtual view just as it breaks an ETL.

Therefore, the agreement with the data team that maintains the source is part of the implementation: advance notice of schema changes, a known maintenance window, and an agreed-upon query budget.

## Effective Hybrid Patterns

**Summary In, Detail Out** - Bring summarized values for each customer into the unification layer, leaving detailed records in the warehouse for on-demand access. This is the most common and usually the most cost-effective pattern.

**Hot Window, Cold Archive** - The last 12-24 months are copied in for performance, and older history remains accessible virtually.

**Virtual First, Copy On Sight** - Start with virtual access, measure actual usage frequency, and only copy what is proven to be frequently needed. This is an efficient way to avoid copying data that no one will ever query.

The connection between this decision and the division of responsibilities between systems is detailed in [Data 360 vs. CRM Data](/en/insights/data-360-vs-crm-data) and [Source of Truth in an Organization](/en/insights/salesforce-source-of-truth).

## Scenario: Financial Company with 400 Million Rows

A financial services company wanted customer segmentation based on seven years of transaction history – approximately 400 million rows in a cloud data warehouse. The original plan was full ingestion into the unification layer.

The pilot changed the decision. It was measured that the actual segmentations relied on only three calculations – monthly average, 90-day trend, and activity classification – all of which could be computed within the warehouse itself. Instead of transferring 400 million rows, three summarized columns per customer, updated daily, were transferred, while the detail remained virtually accessible for ad-hoc investigation.

What was decided here was not "virtual vs. copy" but rather the level of granularity: the correct question was the resolution at which the data was actually needed. Once answered, the copying question became trivial.

## Common Risks and Preventive Actions

| Risk | How it appears in practice | Preventive Action |
| --- | --- | --- |
| Unexpected compute cost | Broad queries at high frequency | Measure in pilot and agree upfront |
| Dependency on source availability | Warehouse outage brings down segmentation | Fallback or hot window copied |
| Schema changes | Views break without warning | Change agreement and schema monitoring |
| Undefined permissions | Broader exposure than at the source | Query identity and written exposure policy |
| Incorrect granularity | Transferring detail that no one uses | Determine resolution before method |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Performance | Response time for key segmentation queries | Monthly |
| Cost | Compute and traffic cost per Use Case | Monthly |
| Stability | Query failures and source availability | Weekly |
| Value | Segmentations and actions actually created | Quarterly |

The choice of a mix between virtual access and ingestion is made within the framework of [Integrations and Data Services](/en/integrations-data).

## Checklist for Zero Copy Decision

- ☐ Concrete Use Cases defined, not "general capability"
- ☐ Freshness requirement determined for each Use Case
- ☐ Actual required data resolution checked
- ☐ Query frequency and scan volume estimated
- ☐ Schema change agreement exists with the source owner
- ☐ Query identity and exposure policy defined
- ☐ Hybrid pattern considered before a binary decision
- ☐ Fallback plan exists for source outage
- ☐ Measured pilot before expansion
- ☐ Owner for cost monitoring and periodic review

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**What real savings does Zero Copy offer?**
Zero Copy eliminates pipeline complexities and data duplication. There's no ETL to maintain, no aging copies, and no confusion about which copy is authoritative. What it doesn't save is computational effort – queries still run, but they do so within the source system's budget where the data resides.

**When is data replication (copying) still the better choice?**
Replication is preferable when low, stable response times are critical for operational use, when the source is unstable or has query rate limitations, when reconstructed historical views are needed for a point in time, or when the source data might disappear. In these scenarios, controlled ingestion is the responsible choice.

**Is Zero Copy suitable for real-time operations?**
Less so. Virtualized queries excel at segmentation, analysis, and enriching context. However, operational processes that demand sub-second responses are better served by pre-calculated values stored closer to the consumer.

**How does governance and permissions work with virtualized access?**
Governance and permissions primarily remain with the source, which is an advantage: there's no separate copy to protect. However, it's crucial to explicitly define the identity used for queries, what data is exposed to whom on the consuming side, and how logging is recorded. Without this, you risk broader exposure than exists in the source system.

**How can I estimate costs upfront?**
Costs are estimated based on three factors: query frequency, the volume of data scanned per execution, and the amount of data transferred between environments and regions. A broad query running every 15 minutes could be more expensive than a daily copy of the same data. Always conduct a pilot before scaling up.

---

## Salesforce Migration Reconciliation & Cutover: Your Go-Live Game Plan
URL: https://hpi.pro/en/insights/salesforce-migration-cutover-reconciliation
Salesforce go-lives often stumble not because of data loading, but due to surrounding events: untracked deltas, premature integrations, or a lack of real-time decision-makers. This guide provides a detailed, hourly cutover plan, freeze policies, a four-level reconciliation methodology, and clear Go/No-Go criteria.

## The Short Answer

A cutover is an operational exercise, not merely a technical step. Three factors determine its success: an hourly plan with a responsible party named for each step, reconciliation that proves data accuracy (not just arrival), and Go/No-Go criteria written when everyone is calm.

The difference between an organization that experienced a smooth transition and one that endured two weeks of chaos nearly always comes down to the number of dress rehearsals—not the quality of the tools.

Detailed planning for the entire cutover is described in [Salesforce Data Migration Guide](/en/insights/salesforce-data-migration-guide).

## Cutover Window Structure: Three Waves

| Wave | When | What's Loaded |
| --- | --- | --- |
| Historical | 3-10 days before | Closed historical data: closed opportunities, closed Cases, past history |
| Delta | During the window | Everything that has changed since the first wave |
| Post-Go-Live | 24-72 hours after | Large files, non-critical data, supplementary information |

This staged approach is what enables a short cutover window. An organization attempting to load everything in a single night will discover that loading time depends on volume, and volume time cannot be compressed beyond platform limitations.

## Sample Timeline - 12-Hour Window

| Hour | Action | Responsible |
| --- | --- | --- |
| T-2 | Confirm Go, check team and decision-maker availability | Project Lead |
| T0 | Freeze source system, disable outbound integrations | IT Ops |
| T0+1 | Extract Delta and verify counts in source | Data Lead |
| T0+2 | Load Delta by dependency order | Migration |
| T0+6 | Automated Reconciliation: counts, sums, relationships | QA |
| T0+8 | Manual sampling and business process owner approval | Business |
| T0+9 | Point of no return: Go / Rollback decision | Steering |
| T0+10 | Activate integrations, open user permissions | IT Ops |
| T0+11 | Smoke Tests for critical processes | QA + Business |
| T0+12 | Go-live announcement to users, transition to hyper-care | Communications |

Two principles govern the schedule: every line item has an owner, and every check has a numerical threshold. A line without an owner will not be executed; a check without a threshold will be resolved through debate.

## Reconciliation: Four Undeniable Levels

**Count** - Number of records in source vs. target, for each entity and each date range. Catches partial loads.

**Sum** - Sums of financial and numerical fields. Catches incorrect conversions, silent truncations, and resets; a correct count alone won't reveal these.

**Relationships** - Number of children per parent, and number of orphaned records. Catches incorrect load order and broken key mapping.

**Manual Sampling** - 20 to 50 pre-selected records, including edge cases: a customer with special characters, an opportunity in foreign currency, a merged record. This is the only level that catches a semantic error—data successfully loaded into the wrong place.

The dependency between conversion accuracy and mapping quality is explained in [Data Mapping for Migration](/en/insights/salesforce-data-mapping).

## Scenario: The Cutover Halted at Hour Eight

A distribution company planned a ten-hour cutover window over a weekend. The loading proceeded, counts matched precisely, and the team prepared to go live. During manual sampling, it was discovered that for six of 30 reviewed customers, open opportunities were misassigned to the wrong owner—a result of a user mapping table not updated after two departures and a role change.

Counts were correct. Sums were correct. Only the sampling caught it. The team didn't perform a Rollback: they identified that 1,400 records could be corrected with a query, executed a targeted fix within the window, and re-verified.

This decision was possible because the No-Go criterion was predefined as "an error not fixable within two hours," rather than "any error." A well-phrased criterion is what allows a tired team to make the right decision at three in the morning.

<h2>Hyper-Care: The 14 Days After</h2>

A cutover window ends with user go-live, but the risk continues. A rapid-response team is needed, with a single point of contact, a daily integration anomalies report, and quality metrics tracking against a baseline. Issues are classified by business impact, not by who yells loudest.

Ongoing quality measurement after cutover is described in [Salesforce Data Quality Metrics](/en/insights/salesforce-data-quality-metrics).

## Common Risks and Preventive Actions

| Risk | How it Manifests | Preventive Action |
| --- | --- | --- |
| Single window for all volume | Load exceeds time, cutover delayed | Split into three waves |
| Awakened integration | Duplicate records or conflicting updates | Controlled disconnection and systematic activation |
| Superficial Reconciliation | Correct counts, incorrect data | Four levels including manual sampling |
| No No-Go criteria | Proceeding due to momentum | Written thresholds before the window |
| Outdated user mapping | Incorrect record ownership | Refresh user table the day before |

## How to Measure Success

| Area | What to Measure | Check Frequency |
| --- | --- | --- |
| Conversion Accuracy | Count, sum, and relationship discrepancies | With each wave and at cutover |
| Schedule Adherence | Deviation from hourly plan | At each Rehearsal |
| Post-Cutover Stability | Integration failures and daily P1 issues | Daily for 14 days |
| Adoption | Logins and actions vs. Baseline | Weekly for the first month |

Support for cutover planning and execution is offered as part of [Integrations and Data Services](/en/integrations-data).

## Go/No-Go Checklist

- ☐ Two full Rehearsal runs with production volume
- ☐ Hourly schedule with an owner for each line item
- ☐ Agreed-upon Freeze plan with the business
- ☐ List of integrations to disconnect and activate, in order
- ☐ Reconciliation script with four levels, as automated as possible
- ☐ Pre-defined manual sample including edge cases
- ☐ User and ownership mapping table updated
- ☐ Written No-Go criteria with numerical thresholds
- ☐ Rollback point and Fix-Forward plan
- ☐ Hyper-care team, single point of contact, and daily report

## Professional Resources

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**How many cutover rehearsals are truly necessary?**
A minimum of two full rehearsals are critical. The second should be performed with production volumes and timing conditions. The first rehearsal identifies content errors, while the second uncovers time and sequence issues – which are the primary culprits for failed cutover windows. Organizations with numerous integrations often perform three.

**How long should the source system be 'frozen'?**
As little as possible, by design. Extended freeze windows generate business resistance and force workarounds outside the system. The standard approach involves a full historical load days before go-live, with only a short delta load during the actual cutover window – typically between four and twelve hours.

**What is the correct way to perform reconciliation?**
Reconciliation should be performed at four levels: record counts per entity, sum totals for financial and numerical fields, parent-child relationship integrity, and manual sampling of 20-50 pre-selected records, including edge cases. The first three levels are automated; the fourth catches semantic errors.

**When do you make a 'No-Go' decision?**
Base 'No-Go' decisions on criteria established *before* the cutover window, not on real-time gut feelings. Triggers include exceeding exception thresholds, financial reconciliation failures, missing predefined intermediate deadlines, or the unavailability of a critical decision-maker. Organizations that don't pre-define No-Go criteria almost always push forward regardless.

**Is a full rollback truly possible?**
Only if meticulously planned. In most cases, a full rollback is only feasible during the initial cutover window, *before* users begin creating new data. Therefore, define a clear 'point of no return' at a specific time. After this point, pivot to a 'fix-forward' strategy with a dedicated hypercare team.

---

## Agentforce Cost: Consumption, Licensing, and Enterprise Agent TCO
URL: https://hpi.pro/en/insights/agentforce-cost-tco
Licensing costs are often easy to calculate but rarely the largest component. This guide breaks down the true Total Cost of Ownership (TCO) into five key elements: licensing, consumption, build, operations, and content maintenance. We introduce a 'cost-per-task' formula that allows for direct comparison of agent costs against human handling, moving beyond vague promises.

## The Short Answer

The question "How much does Agentforce cost?" receives an inaccurate answer when reduced to a license price. The true cost comprises five components: licensing, runtime consumption, initial build, ongoing operations, and content maintenance. In most deployments we've observed, the latter three outweigh the first two combined within the first year.

The decisive metric isn't the monthly cost but the cost per completed, un-escalated task. This is the only figure comparable to existing handling costs, and it also reveals whether the issue lies with pricing or the number of attempts required for completion.

## The Five TCO Components

| Component | What's Included | Behavior Over Time | Sign of Overspending |
| --- | --- | --- | --- |
| Licensing | Platform and user licenses | Fixed, increases with expansion | Licenses purchased before Use Case selection |
| Consumption | Runtime operations based on pricing model | Varies by volume and conversation length | Consumption rising without an increase in completed tasks |
| Build | Discovery, Actions, Grounding, testing | One-time per Use Case, decreases with experience | Scope expanding without business decision |
| Operations | Monitoring, failure review, fixes, change management | Fixed as long as the agent is active | No owner, so no recorded cost – leading to no maintenance |
| Content Maintenance | Knowledge updates, archiving, validity control | Fixed based on number of knowledge domains | Gradual decline in answer accuracy |

## Cost Per Task: The Formula to Build

Calculate the total monthly cost of all five components and divide by the number of successfully completed tasks—meaning those that finished with the desired outcome without escalating to a human. This is the only number that can be compared against the existing handling cost.

Defining "completed" is a difficult decision and requires process owner input. A conversation where the customer received an answer but called back the next day about the same issue is not a completed task. A loose definition creates attractive numbers that don't withstand scrutiny.

It's crucial to compare against a true baseline. The human handling cost includes salary, systems, training, and wait times—not just call duration. Comparing against a partial figure is a common reason why financial justifications collapse during quarterly reviews.

## What Really Increases Costs in Practice

The first factor is weak Grounding. When the agent can't find an accurate source, it tries more often, the conversation lengthens, and consumption increases—ultimately still ending in escalation. Improving content is often a greater cost-saving measure than changing the model.

The second factor is repeated runs after integration failures. Each attempt counts, and when an external system is unstable, the cost multiplies without adding any value.

The third factor is broad scope. An agent designed to answer everything consumes more in each conversation because it checks more sources and performs more considerations. A narrowly focused agent costs less and is more accurate.

The relationship between information source quality and cost is detailed in [Grounding and RAG in Agentforce](/en/insights/agentforce-grounding-rag).

## Budget Controls to Establish in Advance

A defined monthly cap for each Use Case, with an alert before it's reached. Without a cap, overspending is discovered on the invoice.

Cost breakdown by Use Case, not just at the organizational level. When there are three agents and only one total number, it's impossible to tell which one isn't cost-effective and should be shut down.

Weekly measurement of consumption relative to completed tasks. An increase in consumption alongside stable tasks is an early red flag – it indicates a deterioration in answer quality before users complain.

How to set up the monitoring that feeds these controls is detailed in [Observability for AI Agents](/en/insights/agentforce-observability).

## Scenario: A Pilot That Seemed Expensive, Proven Cheap

A software company ran an eight-week pilot and received a consumption bill higher than expected. The initial reaction was to consider stopping. Analysis revealed a different picture: 62% of consumption came from one question category where the agent couldn't find a source and therefore repeatedly tried before escalation.

The solution wasn't technical. Eleven new Knowledge articles were written for that category, and a fallback was defined to escalate after the second attempt instead of trying indefinitely. Monthly consumption significantly decreased, and the number of completed tasks actually increased.

The cost per task—the only metric the CFO reviewed—improved multifold, and the project was approved for expansion. The conclusion: a high invoice is often a symptom of a content gap, not pricing.

## When an Agent Is Simply Not Worth It

Three situations to identify early. Low volume: A process with only a few hundred cases per month won't recoup operational costs, even if it's annoying. Too much variability: When almost every case is an exception, the escalation rate will remain high, along with the doubled cost. And reliance on an unstable external system: The cost is affected by a factor outside the project's control.

In these situations, the correct answer isn't "no to AI" but "no to this process." There is almost always a higher-volume sub-process that does justify the investment.

## Risks and Preventive Actions

| Risk | How It's Discovered | Preventive Action |
| --- | --- | --- |
| Licensing before Use Case | Unused licenses and pressure to show value | Readiness assessment and process selection before purchase |
| No budget for operations | Quality decline after the first quarter | Annual budgeting for monitoring and content maintenance |
| Measurement at organizational level only | Inability to identify an unprofitable agent | Cost breakdown by Use Case |
| Loose definition of "completed" | Attractive numbers that fail scrutiny | Process owner defines success upfront |
| Repeated attempts without a cap | Double consumption without value | Limit attempts and early escalation |

## Economic Metrics

| Metric | Definition | Frequency |
| --- | --- | --- |
| Cost per completed task | Total cost divided by un-escalated tasks | Monthly |
| Consumption per task | Average consumption units per task | Weekly |
| Completion rate | Percentage of cases completing with desired outcome | Weekly |
| Fixed operational cost | Hours for monitoring, fixes, and content maintenance | Monthly |
| Ratio to Baseline cost | Agent cost versus existing handling cost | Quarterly |

When an economic model is needed to withstand internal review before an investment decision, [Agentforce and AI Services](/en/agentforce-ai) is the practical path forward.

## Checklist for Building a Cost Model

- ☐ All five TCO components priced separately
- ☐ "Completed task" defined by the process owner
- ☐ Baseline cost of existing handling measured
- ☐ Monthly consumption cap set for each Use Case
- ☐ Cost breakdown available at the Use Case level, not just organization
- ☐ Monitoring and content maintenance budgeted for the first year
- ☐ Maximum number of attempts before escalation defined
- ☐ Economic threshold for suspending or shutting down an agent established

### Questions and answers
**What truly makes an agent more expensive than anticipated?**
Three key factors drive unexpected costs: longer-than-planned conversations due to weak grounding, repeated failures, and content maintenance that was never budgeted. Consumption costs often stem not from the unit price, but from the number of units consumed per successfully completed task.

**How do you compare agent costs to human agent costs?**
Calculate the cost per successfully completed task with no escalation, not merely the cost per interaction. If an agent handles 80% of a conversation then escalates, the savings are in reduced human effort, not a complete resolution. A fair comparison must include the human agent's time required for post-escalation completion.

**Do operational costs decrease over time?**
While build costs may decrease, operational costs don't necessarily. Monitoring, reviewing failed conversations, and content updates are ongoing expenses as long as the agent is active. Organizations that only budget for the project and not the first year of operations often discover this gap by the second quarter.

**What's a reasonable allocation for content maintenance?**
In practice, this requires a dedicated part-time resource for active knowledge domains – someone who updates articles, archives outdated information, and validates content. Without this allocation, response quality gradually declines, eventually leading to a higher-cost reinvestment decision.

**When is the correct conclusion not to deploy an agent?**
When the cost per task remains higher than the value it generates, even after optimization, or when the volume is too low to justify ongoing operations. Processes involving only a few hundred cases per month are almost always more cost-effectively handled through classic automation or process improvement.

---

## Agentforce Security & The Shared Responsibility Model
URL: https://hpi.pro/en/insights/agentforce-security-shared-responsibility
While the platform secures the infrastructure, your organization is responsible for what the agent can see and do. This guide outlines the practical division of responsibility—data access, permissions, instructions, actions, and monitoring—and highlights new risks introduced by AI agents that have no equivalent in a traditional CRM system.

## The Short Answer

The shared responsibility model isn't just a formal document—it's the line that determines who's at fault when something goes wrong. The simple rule: the platform is responsible for securing the service itself, while the organization is responsible for every decision regarding what an agent sees, what they are allowed to do, and who they respond to.

The major risk isn't a platform breach. It's an over-privileged agent disclosing information to the wrong party or performing an action they shouldn't have—both failures stemming entirely from the organization's side.

## Practical Division of Responsibilities

| Area | Platform's Responsibility | Organization's Responsibility |
| --- | --- | --- |
| Infrastructure | Encryption, isolation, availability, vulnerability management | Choosing environment and approved network configuration |
| Data | Storage and processing according to agreement | What gets indexed and what's classified as sensitive |
| Identity & Permissions | Platform's authorization mechanisms | Defining who is allowed to see and do what |
| Agent Behavior | Model capabilities and control tools | Instructions, boundaries, approval points |
| Actions | Execution infrastructure | Authorization for each Action and validation within it |
| Monitoring & Auditing | Platform logs | Business audit trail, sampling, and review |

## New Risks Not Present in Regular CRM

The first is exposure through retrieval. In a regular system, the user sees what the screen displays; with an Agent, free text can cause a snippet from an unauthorized document to be retrieved. Therefore, retrieval must run within the user's permission context, not within a broad integration account context.

The second is Prompt Injection. Content the Agent reads—a customer email, description field, attached document—might contain instructions attempting to alter its behavior. This cannot be defended against by phrasing alone; the defense is architectural.

The third is internal content leaking to an external channel. An article written for representatives with discount margins or objection handling scripts should not reach the customer, and separation must be based on a whitelist, not a blocklist.

The fourth is silent privilege escalation: adding an Action or permission to solve a specific problem, without going through the approval process.

## Five Controls That Bear the Most Weight

Retrieval in the user's context. This is the only control that, if broken, renders all others useless.

Separate authorization for each Action, following the principle of least privilege. An Agent granted a single broad profile prevents all future control.

Validation within the action, not in instructions. An instruction is guidance; validation is a control. An action that performs a credit must verify amount, eligibility, and authorization in its code, even if instructions tell the Agent not to trigger it in certain cases.

Human approval for irreversible actions. This control converts a potential failure into an event stopped in time.

Audit trail linking user, action, source, and approver. Without it, there's no answer to the audit question, "On what basis did the Agent do that?"

General Salesforce permission model principles are detailed in [Salesforce Permission Model](/en/insights/salesforce-permission-model).

## What to Check Before Go Live

Persona Tests: The same ten to twenty questions are run under different identities—representative, manager, restricted user, external customer—and answers are compared. Any discrepancy not explained by permissions is a finding.

Content Red Teaming: Deliberate attempts to extract unauthorized information, trigger prohibited actions, and bypass escalation. Scenarios are written once and saved for re-running with each version.

Action Path Testing: For each Action, verify that validation works even when triggered directly, not just through the Agent.

Data Retention Testing: What data is stored, for how long, and who can access logs containing conversation content with customer data.

How these tests integrate into a broader testing framework is explained in [Agentforce Testing Scorers](/en/insights/agentforce-testing-scorers).

## Scenario: Finding Caught in Persona Testing

A healthcare company developed an internal Agent to answer procedural questions. During Persona Testing before go-live, it was discovered that an administrative user received an answer based on a procedure classified for medical staff only.

The reason wasn't an Agent bug. The index was built by an integration account with broad access, and retrieval did not restrict by user permissions. The same exposure was potentially present in any question touching that area.

The fix involved two things: moving retrieval to the user context and explicitly marking classified documents so they wouldn't enter the general index. The test was added as a permanent scenario run before every version release.

## Risks and Preventive Actions

| Risk | How it's Detected | Preventive Action |
| --- | --- | --- |
| Retrieval with broad permissions | Exposure of a classified document in an innocent answer | Retrieval in user context and Persona Tests |
| Prompt Injection | Action triggered by external content | Narrow permissions, in-action validation, human approval |
| Mixing internal and external content | Internal phrasing reaching customer | Whitelist on external channel |
| Silent privilege escalation | Agent doing more than authorized | Tagging significant changes and re-approving |
| No Audit trail | No answer for audit | Logging user, action, source, and approver |

## Security Metrics

| Metric | What it Reveals | Frequency |
| --- | --- | --- |
| Persona findings | Permission gaps in retrieval | With each version |
| Red Teaming results | Resilience against bypass attempts | With each version |
| Sensitive actions without approval | Gaps in control path | Monthly |
| Changes that bypassed approval | Change process discipline | Quarterly |
| Audit trail coverage | Percentage of fully documented sensitive actions | Quarterly |

The approval framework within which controls are enforced is detailed in [AI Governance for Agentforce](/en/insights/agentforce-ai-governance).

When guidance is needed in defining the responsibility model and pre-go-live testing, [Agentforce and AI Service](/en/agentforce-ai) is the practical next step.

## Pre-Go Live Security Checklist

- ☐ Shared responsibility document written and approved
- ☐ Data usage terms with the model documented in writing
- ☐ Retrieval runs within the user's permission context
- ☐ Persona tests conducted for all permission levels
- ☐ Each Action has separate permission and internal validation
- ☐ Irreversible actions require human approval
- ☐ External channel operates a content whitelist
- ☐ Content Red Teaming scenarios written and executed
- ☐ Audit trail links user, action, source, and approver
- ☐ Log and conversation content retention policy approved

### Questions and answers
**What aspects does the Agentforce platform cover, and what falls outside its scope?**
The platform secures the core infrastructure, encryption, environment isolation, and contractual data usage agreements with the underlying AI models. However, it does not dictate who in your organization sees what, which actions the agent is authorized to perform, what content feeds into the knowledge base, or who monitors these interactions. These organizational decisions introduce the majority of an agent's operational risk.

**What exactly is 'Prompt Injection' in an enterprise setting?**
Prompt injection refers to malicious or unintentional content—such as an inbound email, description field entry, or uploaded document—that the agent processes, containing instructions designed to alter its intended behavior. Effective defense isn't solely about crafting better prompts but implementing robust controls: granular action permissions, in-action validation, and human approval before sensitive operations are executed.

**Will our organization's data be used to train AI models?**
The answer solely depends on your official agreement and specific configuration. This must be meticulously documented in writing *before* going live; never rely on assumptions. This is one of the first questions internal audit will ask, and a documented answer, not a recollection from a sales call, is crucial.

**Is a penetration test necessary for an AI agent?**
Yes, but it requires a specialized approach. Beyond standard technical penetration testing, 'red teaming' for content and behavior is essential. This involves attempting to extract unauthorized information, coerce the agent into performing unapproved actions, and bypassing escalation protocols. These tests should be scripted as scenarios and retained for repeated execution with every new agent version or update.

**What is required for audit and regulatory compliance with AI agents?**
A comprehensive audit trail is critical, documenting for every sensitive action: the user, what the agent did, the source of its information, and who approved it. Additionally, an up-to-date agent registry and a clear document outlining the shared responsibility matrix are non-negotiable. These three elements will address the vast majority of audit inquiries.

---

## Agentforce Testing: Test Sets, Scorers, & Edge Cases
URL: https://hpi.pro/en/insights/agentforce-testing-scorers
Testing an AI agent isn't like testing a Flow – the same question might have multiple valid answers. This guide shows you how to build a realistic test set, what dimensions to measure, when automation is enough versus needing human judgment, and what threshold ensures a successful go-live.

## The Short Answer

Agent testing isn't classic software testing. There's no single correct answer; the same question can be phrased twenty ways, and a "failure" is often a reasonable response lacking a critical condition, not an error. Therefore, a different approach is needed: a representative set of test cases, acceptance criteria instead of precise answers, and measurement across several distinct dimensions.

Separating these dimensions is what makes testing useful. "The answer isn't good" isn't a finding; "the topic was correctly identified, but the relevant source wasn't retrieved" is a fixable finding.

## The Four Dimensions of Measurement

| Dimension | What is tested | How it's measured | Who fixes it |
| --- | --- | --- | --- |
| Topic Identification | Did the agent understand the core issue | Comparison to the expected topic | The team writing instructions and Action descriptions |
| Retrieval | Was the correct source material fetched | Did the expected passage appear in the retrieval | Content owner and tagger |
| Response | Is the content accurate and complete | Acceptance criteria: mandatory, forbidden, citation | Content and instructions |
| Process | Was the correct Action triggered and escalation maintained | Review of action sequence and stopping decision | Actions and escalation rules |

## Building a Representative Test Set

The source material should be real customer interactions, not scenarios crafted in a meeting. Transcripts, emails, and Case descriptions capture what's missing from invented scenarios: typos, partial phrasing, two questions in one sentence, and missing information.

A recommended breakdown: about half common cases, about a quarter edge cases—exceptions, borderline eligibility conditions, multi-part questions—and about a quarter cases intentionally designed to fail: out-of-scope requests, attempts to extract unauthorized information, and customers demanding a human agent.

For each case, define four fields: the actual inquiry as phrased, the expected topic, the acceptance criterion for the response, and the expected process behavior—including "should escalate" as a valid outcome, not a failure.

## Acceptance Criteria Instead of Precise Answers

This principle is what makes testing possible at all. Instead of writing the "correct" answer, create three short lists: facts that *must* appear, statements that are *forbidden* from appearing, and the source that *must* be cited.

A typical example: a question about refund eligibility. The timeframe and product condition *must* appear; a commitment to a refund *must not* appear; the source *must* be the current version of the return policy. Two completely different phrasings could both pass.

This is also the format that enables reliable automated scoring—checking for the presence of a precisely defined fact is far more accurate than asking a model to evaluate "quality."

## Automation vs. Human Judgment

Automated scorers are suitable for topic identification, presence of a valid citation, format compliance, length, and identifying forbidden statements. These run on the entire set for every version, at a low cost.

Human judgment is required for content accuracy in sensitive areas and for customer-facing phrasing. The entire set isn't needed—a fixed sample of twenty to thirty cases per version, selected to include edge cases, is sufficient.

The danger of relying solely on an automated scorer is a bias towards responses that sound authoritative. A persuasive answer that omits an eligibility condition will pass automatically but fail with a human reviewer.

How test results link to production monitoring is explained in [Observability for Agentforce](/en/insights/agentforce-observability).

## Edge Cases to Always Include

A question with two topics in one sentence. An inquiry missing critical information—does the agent ask clarifying questions or guess? A customer phrasing in a negative tone—is escalation triggered? A request for an action not permitted for that user. A question about a non-existent product—does the agent admit it or hallucinate? Content containing a disguised instruction attempting to alter behavior.

These six cover most failures observed in production, and they are inexpensive to re-run.

Bypass scenarios tie into the security tests detailed in [Agentforce Security and Shared Responsibility](/en/insights/agentforce-security-shared-responsibility).

## Go-Live Thresholds

The threshold isn't a single number but is derived from the channel and risk. An internal agent assisting a representative can go live with a lower accuracy level because the representative filters the output. A customer-facing agent requires a significantly higher threshold, and crucially, zero failures in critical categories.

The rule more important than the number: zero failures in mandatory categories. Exposure of unauthorized information, irreversible action without approval, failure to escalate a direct request for a human—each of these blocks go-live regardless of the overall score.

## Scenario: A Small Set Prevented a Bad Launch

A tourism company planned to launch a customer agent after an internal pilot showed good performance. The test set included 90 cases, 22 of which were edge cases from real inquiries.

The run revealed a pattern: for questions about changing dates with special cancellation conditions, the agent provided a mostly correct answer but omitted change fees in a third of the cases. This wasn't caught in internal tests—representatives knew to add the information themselves.

The launch was delayed by three weeks. The fix was in the content: billing conditions were moved to a separate, clearly marked section in all relevant articles, and an explicit acceptance criterion was added. The re-run passed, and the launch proceeded without incident.

## Risks and Preventative Actions

| Risk | How it's detected | Preventative action |
| --- | --- | --- |
| Invented test set | Everything passes in testing, fails in production | Cases from real inquiries |
| Testing only by overall score | It's unclear what to fix | Separate measurement for the four dimensions |
| Relying on automated scoring | Persuasive answers with omissions pass | Fixed human sample in each version |
| No cases designed to fail | The agent answers what it shouldn't | A quarter of the set: out-of-scope and bypass |
| No regression | A small fix breaks another scenario | Run the set before every version release |

## Test Metrics

| Metric | Definition | General Threshold |
| --- | --- | --- |
| Topic accuracy | Percentage of correct topic identification | High; failure here breaks everything else |
| Retrieval hit rate | Percentage of cases where the expected source was retrieved | High in customer channels |
| Answer acceptance | Percentage of answers meeting acceptance criteria | Derived from channel and risk |
| Process compliance | Percentage of cases where the correct Action or escalation was triggered | Zero deviations in mandatory categories |
| Regression delta | Change in scores compared to the previous version | No unexplained decreases |

For assistance in building a test set and defining go-live thresholds, [Agentforce and AI Services](/en/agentforce-ai) is the practical next step.

## Testing Checklist

- ☐ Test set built from real inquiries
- ☐ Composition includes common, edge, and intentionally failing cases
- ☐ Each case has acceptance criteria: mandatory, forbidden, source
- ☐ Measurement is split into topic, retrieval, response, and process
- ☐ Automated scorers run on the entire set
- ☐ A fixed human sample is reviewed in each version
- ☐ Bypass scenarios and disguised instructions are included
- ☐ Mandatory categories with zero tolerance are defined
- ☐ The set runs as regression before every version release
- ☐ Test results are documented and compared to the previous version

### Questions and answers
**How many cases are needed for an effective test set?**
For an initial version, 50 to 150 representative cases are usually sufficient. A set of 500 perfectly phrased cases is less useful than 80 cases that include typos, ambiguous questions, out-of-scope requests, and attempts to circumvent rules.

**Where can we source realistic test cases?**
Leverage existing customer interactions: call transcripts, emails, and case descriptions. Team-generated cases often lead to overly perfect phrasing, creating a skewed perspective. The quickest method is to take the last two hundred customer inquiries and filter out duplicates.

**Can we rely on models for automated answer scoring?**
For some dimensions, yes—like topic identification, citation presence, and adherence to format and policy. However, for content accuracy in sensitive areas, human sampling is crucial. Automated graders tend to validate answers that merely *sound* correct. The common approach: automate everything, then apply human judgment to a sample.

**What constitutes a 'failure' when multiple correct answers exist?**
Instead of a single correct answer, define clear acceptance criteria: what facts *must* be present, what information is *forbidden*, and what sources *must* be cited. This allows for diverse, yet equally valid, responses while ensuring an answer that omits eligibility criteria, for example, is flagged as a failure.

**How often should the test set be run?**
Run the full test suite before every new release. Additionally, continuously run a sample against your production environment. A seemingly minor change—like an instruction update, adding an article, or modifying an Action—can impact behavior in unrelated scenarios. Regression testing is the only way to catch these issues before they affect users.

---

## Agentforce Observability: Measuring, Analyzing, and Optimizing Your AI Agent
URL: https://hpi.pro/en/insights/agentforce-observability
An AI agent without proper monitoring is a black box, leaving you unable to defend its performance in boardroom discussions. This guide breaks down observability into three key levels—individual conversation traces, trend analysis, and business outcomes. We'll explain essential trace elements and how to transform failed conversations into a actionable weekly backlog instead of an unread report.

## The Short Answer

Agent monitoring differs significantly from traditional system monitoring. An agent rarely "crashes"; it simply performs less effectively. Therefore, classic metrics like availability and error rates are insufficient. An additional layer is needed to measure decision quality, not just technical functionality.

A practical structure includes three levels: a Trace to explain a single conversation, weekly Trends to detect deterioration, and a Business Outcome metric to justify continued operation. Each level addresses a different question and serves a different audience.

## Three Levels of Monitoring

| Level | Question It Answers | Audience | Frequency |
| --- | --- | --- | --- |
| Trace | Why did this conversation end this way? | Technical Team & Analyst | On Demand |
| Trend | What is changing for better or worse? | Process Owner & Platform Manager | Weekly |
| Outcome | Does the agent justify its existence? | Management & Sponsor | Monthly & Quarterly |

## Level 1: Essential Trace Components

A useful Trace allows you to reconstruct a decision without needing to ask anyone. Seven components are crucial: the prompt as phrased, the identified topic, the actually retrieved sections, the activated actions with their parameters, the result of each action, validation points and their decisions, and the reason for termination.

The often-overlooked component is the retrieved sections. Without it, it's impossible to distinguish between two completely different failures: the agent couldn't find the information, or it found it but used it incorrectly. The first is addressed with content, the second with instructions – and misdiagnosing this has wasted weeks in every organization we've seen.

You also need to link the Trace to a business record: a Case, Order, or Opportunity. Without this link, it's impossible to verify if the conversation ultimately led to a resolution or a repeat inquiry.

## Level 2: Trends Worth Tracking

Five metrics suffice for most deployments: completion rate without escalation, repeat inquiry rate within a week, percentage of answers with a valid source, action failure rate, and consumption relative to tasks completed.

Interpretation is done in pairs. High containment with a high repeat inquiry rate is not a success. Consumption increasing while tasks remain stable means the agent is working harder for the same result—an early sign of content degradation.

Automated alerts are configured for relative changes, not absolute values: a jump in escalation rate, a drop in the percentage of valid sources, an increase in action failures against a specific external system.

The connection between these metrics and cost is detailed in [Agentforce Cost & TCO](/en/insights/agentforce-cost-tco).

## Level 3: Business Outcome

This is the level that dictates the outcome of the quarterly review. Two numbers: what has changed in our predefined process metrics—handle time, churn, agent contact volume—and what is the cost of a completed task compared to a Baseline.

It's crucial to define these metrics upfront and not change them after seeing results. Changing the definition of “success” mid-flight is the biggest destroyer of management confidence in data, even when the change is justified.

## From Analysis to Improvement Backlog

The weekly report is not the deliverable. The deliverable is a work queue. The effective practice is: sample twenty failed or escalated conversations, classify them by root cause—content gap, incorrect tagging, unclear instruction, action failure, or out-of-scope request—and create a work item for only the largest category.

The rule to prevent distraction: address one root cause per week. Organizations that try to fix five concurrently never know in the end what improved the metric and what worsened it.

Content gaps identified here are direct input for the writing backlog – the process is detailed in [Knowledge Management for Agentforce](/en/insights/agentforce-knowledge-readiness).

## Scenario: A Quiet Decline Caught in Time

A financial services company deployed an internal agent that was stable for four months. In the fifteenth week, the escalation rate gradually increased without anyone complaining – agents simply took over and completed the handling themselves.

The alert configured for a relative increase in escalations triggered an investigation. Sampling Traces showed that in half of the new cases, no relevant section was retrieved. The reason: a product policy change led to the automatic archiving of eleven articles, and no alternatives were written.

The fix took two days and required no changes to the agent. Without the monitoring layer, the gap would have only been discovered when a manager asked why average handle time had increased—likely a quarter later.

## Risks and Mitigation Actions

| Risk | Appearance | Mitigation Action |
| --- | --- | --- |
| Technical monitoring only | Everything is green, but answers are worse | Quality & escalation metrics alongside availability |
| Trace without retrieval content | Months of guessing between content and model | Mandatory logging of retrieved sections |
| Report without work queue | Data presented but nothing changes | Weekly sampling and work item for one root cause |
| Changing definitions mid-way | Loss of confidence in data | Define success metrics upfront |
| No link to business record | Cannot identify repeat inquiries | Link Trace to Case or Order |

## Recommended Dashboard

| Metric | Definition | Alert Threshold |
| --- | --- | --- |
| Completion Rate | Resolution without escalation or repeat inquiry | Significant relative week-over-week drop |
| Escalation Rate | Percentage of transfers to a human agent | Sustained relative increase |
| Valid Source | Percentage of answers with existing and valid citation | Drops below a defined threshold |
| Action Failures | Percentage of failed actions by target system | Increase in failures against a specific target |
| Consumption per Task | Consumption units per completed task | Increase without proportional task growth |

When guidance is needed to establish a monitoring layer and weekly improvement process, the [Agentforce & AI Service](/en/agentforce-ai) is the practical next step.

## Observability Setup Checklist

- ☐ Trace records prompt, topic, retrieved sections, actions, and result
- ☐ Every Trace is linked to a business record
- ☐ Retention policy differentiates between metadata and conversation content
- ☐ Only five to seven trend metrics have been selected
- ☐ Alerts are defined for relative changes, not absolute values
- ☐ A routine for weekly sampling of failed conversations exists
- ☐ A taxonomy of root causes of failure has been defined
- ☐ The business process owner participates in the weekly review
- ☐ Success definitions were established before measurement began

### Questions and answers
**What essential information should be included in a conversation trace?**
A comprehensive trace should include the user's original query, the identified topic, the actual content snippets retrieved, the actions triggered and their parameters, the outcome of each action, any human approval points and their decisions, and the reason for the conversation's conclusion or escalation. Without the retrieved snippets, it's impossible to distinguish between content issues and model issues.

**How long should conversation traces be retained?**
Retain traces long enough to investigate quarterly trends, while adhering to data retention policies and regulations. Conversation content containing customer data is typically retained for a shorter period than metadata, so it's common practice to separate: long-term storage for metrics and metadata, and shorter-term storage for full conversation content.

**Is an external monitoring tool necessary for Agentforce observability?**
Not initially. An internal dashboard showcasing five to seven key metrics and a dedicated queue for failed conversations is usually sufficient for the first year. An external tool becomes justified when you manage multiple agents, across various channels, and require cross-referencing with other enterprise monitoring systems.

**How can I determine if a drop in quality is due to the AI model or the content?**
Examine the retrieval step within the trace. If the correct content snippet wasn't retrieved, it indicates a content or tagging issue. If the correct snippet was retrieved but the answer is still incorrect, the problem lies in the agent's instructions or response generation. This distinction saves weeks of guesswork.

**Who should be actively reviewing the observability data?**
The relevant business process owner should review the data weekly, in collaboration with the platform administrator. Monitoring that remains solely with the technical team will identify technical failures, but often misses answers that are technically correct yet commercially detrimental – which is the more prevalent type of failure.

---

## Build vs. Buy in Agentforce: Standard Actions, Flow, Apex & APIs
URL: https://hpi.pro/en/insights/agentforce-build-vs-buy-actions
Every action an agent performs can be implemented in four ways, and the distinction isn't merely technical. It impacts maintenance, testing, and modification timelines. This guide provides a clear decision-making framework, outlines the maintenance costs of each option, and identifies scenarios where Apex is the optimal choice despite its higher cost.

## The Short Answer

Actions are where an agent stops talking and starts doing, which is why they concentrate most of the risk and maintenance costs. There are four implementation methods: Standard Actions, Flow, Apex, and External Services via an external API. The choice between them isn't about capability—almost any action is possible with all of them—but about who maintains it, how quickly it can be changed, and how it’s tested.

The recommended order of choice is top-down: start with a Standard Action, move to Flow when business logic is needed, to Apex when complexity is real, and to External Services when the source of truth is outside Salesforce. Each step down the ladder adds maintenance cost and thus requires justification.

## The Decision Table

| Implementation | When Suitable | Who Maintains | Cost of Option |
| --- | --- | --- | --- |
| Standard Action | Retrieve, update field, open Case, summarize record | Platform administrator | Limited flexibility for business rules |
| Flow | Changing business rules, multiple steps, validation | Admin or process owner | High-volume performance, limited error handling |
| Apex | Complex logic, massive processing, error control | Developer only | Every change requires deployment cycle and testing |
| External Services / API | Source of truth outside Salesforce | Integration team | Dependence on availability, latency, and third-party versions |

## First Rule: Description Before Implementation

Before choosing a technology, write a description of the action. This might sound procedural, but it’s the element that determines whether the agent triggers the correct action. The agent doesn't read the code—they read the description and decide based on it.

A good description includes three parts: what the action does, when to use it, and explicitly when *not* to use it. The third part is often forgotten, and it's what prevents the agent from triggering a refund action when the customer merely inquired about refund policy.

Parameters should be minimal and of a defined type. A free-text parameter where the agent is supposed to fill in a value from a closed list is an invitation to errors; a defined picklist solves this without additional logic.

## When Flow and When Apex

Flow is the default for business rules because it's visual and allows the process owner to see what’s happening. For agents, an additional advantage is the speed of correction: if it's discovered that an action doesn't check eligibility conditions, it can be fixed the same day.

Apex is justified in four situations: logic with many branches that makes Flow unreadable, processing large volumes in a single call, requiring precise control over error handling and transactions, and integration that demands complex response processing. Outside of these situations, Apex primarily increases the cost of the next change.

The choice is also related to existing technical debt. An organization already carrying thousands of lines of Apex without tests should think twice before adding another layer—the full considerations are in [Flow vs. Apex](/en/insights/salesforce-flow-vs-apex).

## Actions with External Systems

This is the area where failures reach the end-user. Three decisions must be made before building: what is the maximum waiting time, what does the agent say if the call fails, and is a retry allowed?

Idempotency is the crucial concept. A read operation can be safely retried. An action that creates a record, sends a message, or charges a card—retrying could lead to duplication. The solution is a unique key for each request that the receiving system recognizes, or a conscious decision to forgo retries.

Latency is an experience consideration, not just a technical one. A call taking a few seconds is acceptable in a chat channel if the agent says they are checking; a call taking longer requires an asynchronous path—the agent confirms receipt and updates when the answer arrives.

Patterns for handling integration failures are detailed in [Salesforce Integration Error Handling](/en/insights/salesforce-integration-error-handling).

## Action-Level Permissions

Every Action should be restricted by a separate permission. A common mistake is to grant the agent a broad profile covering all actions, which then makes it impossible to open one action to a specific group without opening all of them.

The working principle: minimum permission for each action, validation within the action itself and not just in the instructions to the agent, and verification that the action respects the user's context. Do not rely on instructions to prevent activation—instructions are guidance, not control.

## When to Split an Action

An action that does three things is difficult to test and difficult to approve. A sign for splitting: when part of the action requires human approval and part doesn't, when different parts require different permissions, or when a failure in the middle leaves the process in an inconsistent state.

Splitting slightly increases orchestration cost but pays off: each part is tested separately, the agent can pause between parts, and permissions are precise. The practical rule—one action, one judgment.

Planning the breakpoints between parts is detailed in [Human-in-the-Loop in Agentforce](/en/insights/agentforce-human-in-the-loop).

## Scenario: An Organization Switched from Apex Back to Flow

A service company built six Apex Actions in a pilot, assuming this would give them full control. Within two months, it became clear that four of them changed logic three times each—not due to bugs, but because business rules became clear during use. Each change required a developer, testing, and a deployment cycle of several days.

In the second round, the two actions that remained in Apex were those with multiple calls to an external system and response processing. The other four were moved to Flow, and the platform administrator took responsibility for them. The average time to repair dropped from days to hours.

The lesson wasn't that Apex is bad, but that at a stage where rules are still evolving, the cost of change is more important than the initial build cost.

## Risks and Preventative Actions

| Risk | How it Manifests | Preventative Action |
| --- | --- | --- |
| Ambiguous action description | Agent triggers the wrong action | Description with "when yes" and "when no" and defined parameters |
| Blind retry | Duplicate records or charges | Unique request key or waive retry |
| Broad agent permission | Sensitive action accessible to all users | Separate permission for each Action and validation within the action |
| All logic in Apex | Every business change becomes a development project | Flow for evolving rules, Apex for true complexity |
| Action does three things | Failure in the middle leaves an inconsistent state | Split by judgment and permission |

## Metrics for Actions

| Metric | What It Reveals | Frequency |
| --- | --- | --- |
| Action success rate | Percentage of successful executions | Weekly |
| Wrong action rate | Percentage of cases where the wrong action was chosen | Per version |
| Median action latency | Whether the experience remains reasonable | Weekly |
| Integration failure rate | Stability of target systems | Weekly |
| Mean time to repair | Does the chosen implementation allow rapid change | Monthly |

When guidance is needed in planning the Actions layer and adapting it to the existing architecture, the [Agentforce and AI Service](/en/agentforce-ai) is the practical next step.

## Checklist for Each Action

- ☐ Description written with "what," "when yes," and "when no"
- ☐ Parameters are minimal and of a defined type
- ☐ The highest sufficient implementation method was chosen
- ☐ A separate permission was defined for the action
- ☐ Validation resides within the action, not just in instructions
- ☐ It was determined whether the action is idempotent and what the retry policy is
- ☐ Maximum waiting time and user failure message were defined
- ☐ Multi-judgment actions were split
- ☐ A test scenario exists for failure, not just success

### Questions and answers
**Why not just build everything in Apex and be done with it?**
Because every Apex-based Action makes subsequent changes dependent on developers and deployment cycles. For actions driven by evolving business rules, Flow empowers process owners to make updates independently. Apex is justified when dealing with complex logic, massive data processing, or calls requiring precise error handling.

**Are Standard Actions sufficient for a pilot?**
Usually yes, and intentionally so. A pilot starting with record retrieval, field updates, and case creation can be built in days, not weeks. This allows you to validate the crucial question – does the agent correctly identify when to use the action – before investing in significant development.

**How does an agent know when to trigger a specific Action?**
Based on its description. Vague descriptions are the most common reason agents activate the wrong action. A good description clearly explains what the action does, when to use it, explicitly when NOT to use it, and uses terminology consistent with user inquiries.

**What happens when a call to an external system fails mid-process?**
You need a predefined strategy: clear user messaging, failure logging in Trace, and a retry policy only for idempotent operations. Actions that create records or charge cards should never be blindly retried to avoid duplicates.

**When should one complex action be split into several smaller Actions?**
When the action performs more than one distinct function, or when part of it requires human approval while another part does not. Splitting allows for assigning different permissions to each part, testing each independently, and enabling the agent to pause mid-process without leaving an incomplete transaction.

---

## Knowledge Management for Agentforce: Prepping Unstructured Data for AI
URL: https://hpi.pro/en/insights/agentforce-knowledge-readiness
A knowledge base built for humans isn't ready for an AI agent. It contains conflicting versions, orphaned documents, and internal content mixed with customer-facing information. This guide outlines a five-stage preparation process – audit, archive, structure, tag, and ownership – with clear indexing thresholds and a sustainable maintenance model.

## The Short Answer

An enterprise knowledge base is typically built for humans, who can fill in gaps, identify outdated documents, and ask a colleague. An agent cannot do any of these three things. Therefore, training should focus less on adding content and more on removal, decision-making, and tagging.

The practical process involves five steps: reviewing coverage and validity, archiving conflicting and outdated records, reorganizing article structure, tagging for retrieval, and assigning ownership with SLAs for updates. The fifth step determines if the investment will last beyond six months.

How the retrieval layer consumes this content is explained in [Grounding and RAG in Agentforce](/en/insights/agentforce-grounding-rag).

## Step 1: Focused Review

Don't review the entire knowledge base. Take the list of scenarios the agent will handle and generate a list of real questions—from actual received inquiries, not imagination. For each question, check: Is there an article? When was it last updated? Who owns it? Is the answer still correct today?

The result yields four categories: covered and valid, covered but outdated, covered by several conflicting versions, and not covered at all. The third category is the most dangerous, as it causes the agent to give different answers to the same question.

The gap found in the fourth category isn't necessarily a problem—it becomes the writing backlog and, in the meantime, a list of topics that are routed to a human.

## Step 2: Archive Before Writing

The hardest instruction for organizations to accept is to delete. But an outdated article remaining in the knowledge base causes more damage than a missing one: missing leads to escalation, outdated leads to a confidently incorrect answer.

A simple rule of thumb: any article without an owner that hasn't been updated beyond its defined period for its subject matter is removed from the index. It can remain in an archive for documentation purposes but is not accessible to the agent.

In a conflict between two versions, the decision rests with the content owner, not the technical team. This is a point that requires a business decision, and skipping it brings the problem back during testing phases.

## Step 3: Article Structure

A good structure for an agent is also a good structure for a reader, so this isn't duplicate work. The title is phrased as a question or scenario using user-facing language, not internal jargon. The first paragraph provides a short, self-contained answer. Details are then presented in sections with subheadings.

Two rules directly impact retrieval quality: eligibility conditions and exceptions should be in a separate, clearly marked section, not interwoven into a sentence; and tables should remain small and self-contained, because a table cut off mid-way produces a partial answer.

What to avoid: long articles that cover five topics. It's better to split them into five focused articles—retrieval is more accurate and maintenance is easier.

Broader knowledge management principles in Service Cloud are detailed in [Knowledge Management in Salesforce](/en/insights/salesforce-knowledge-management).

## Step 4: Tagging and Audience Separation

Minimal tagging required in almost every organization: product or service line, market or country, language, target audience, approval status, and validity date. In a global organization, the lack of market and language tagging is the number one cause of incorrect answers—the agent will confidently pull a policy from a different country.

Audience separation is a security decision, not just a classification. Content written for agents sometimes contains discount margins, objection handling scripts, and competitive information. For a customer channel, the default should be a whitelist: only content explicitly marked as customer-approved is included.

A document that is mostly permissible but has one sensitive paragraph is not an edge case—it's common. The solution is to split the document, not mark the entire thing as internal.

## Step 5: Ownership and Maintenance

This is the step that determines if the outcome will endure. For each knowledge area, assign a named owner, set a review frequency, and define what happens when an article passes its expiration date—automatic removal from the index, not an alert that no one reads.

The feedback mechanism is what makes maintenance effective. Any conversation that ended in escalation due to a missing source is added to the content gap list, and this is the best priority list for new writing. It's better to write five articles that were actually needed than fifty that seemed important.

Budget: Content maintenance is an ongoing expense, not a project. Organizations that treat it as a one-time task see a decline in accuracy within two quarters.

## Index Entry Thresholds

| Criterion | Minimum Threshold | Why |
| --- | --- | --- |
| Ownership | Named owner for each article | Without an owner, there's no one to update it |
| Validity | Within the defined review period for the subject | Prevents quoting canceled policies |
| Uniqueness | Single source for each topic | Prevents conflicting answers |
| Audience | Marked as internal or customer-approved | Prevents exposure of sensitive content |
| Structure | Question title and short answer in introduction | Improves retrieval accuracy |

## Scenario: 1,400 Documents Reduced to 190

An IT service provider wanted to connect an agent to a SharePoint folder with 1,400 documents. Initial review showed that only about 30% had been updated in the last three years, and about 200 were drafts or working versions.

Instead of a sweeping cleanup project, the team mapped the 25 scenarios the agent was supposed to cover. From the existing repository, 190 relevant documents were found; of these, 40 were conflicting and required a decision from three subject owners. The selected documents were split into focused articles and tagged by product and audience.

The pilot launched with 190 items instead of 1,400, and answer accuracy was significantly higher than the initial attempt. The rest of the repository remained in the archive and was gradually incorporated based on the gap list accumulated from actual escalations.

## Risks and Preventive Actions

| Risk | How it is detected | Preventive Action |
| --- | --- | --- |
| Importing the entire repository | Low accuracy and difficulty in identifying the cause | Import by scenario, not by repository |
| Articles without owners | Silent obsolescence | Ownership as a condition for index entry |
| Conflicting versions | Different answers to the same question | Business decision and archiving |
| Mixing internal and external content | Exposure of sensitive information to the customer | Whitelist for external channel |
| Maintenance as a one-time project | Decline in accuracy within two quarters | Ongoing budgeting and SLA for updates |

## Content Readiness Metrics

| Metric | Definition | Frequency |
| --- | --- | --- |
| Scenario Coverage | Percentage of scenarios with an approved article | Monthly |
| Validity | Percentage of articles in the index within their validity period | Monthly |
| Topical Duplication | Number of topics with more than one source | Quarterly |
| Gaps from Escalations | Number of new topics required but unavailable | Weekly |
| Average Update Time | How long it takes to correct an article found to be incorrect | Monthly |

When support is needed in training the knowledge base and establishing the maintenance model, [Agentforce and AI Service](/en/agentforce-ai) is the practical next step.

## Knowledge Training Checklist

- ☐ A list of real questions from actual inquiries has been created
- ☐ Each question has been categorized: valid, outdated, conflicting, or missing
- ☐ Articles without owners have been archived or assigned owners
- ☐ Conflicts have been resolved by the content owner
- ☐ Articles are structured: question title, short answer, sections
- ☐ Eligibility conditions and exceptions are in a separate section
- ☐ Tagging for product, market, language, audience, and validity exists
- ☐ Internal content has been separated from customer-approved content
- ☐ Review frequency and automatic removal upon expiration have been set
- ☐ A mechanism converting escalations into a writing backlog has been established

### Questions and answers
**Do we need to rewrite all articles before we start?**
No. Begin with the scenarios your agent will handle in the first version—typically twenty to forty articles. A comprehensive rewrite of a knowledge base with hundreds of articles takes months and often stalls midway. Focused preparation is sufficient for a pilot.

**What should we do with articles that have no owner?**
Either assign an owner or archive them. An unowned article will continue to become outdated, and the agent will continue to cite it. This is an uncomfortable decision but far cheaper than discovering post-facto that your agent provided a policy that was deprecated two years ago.

**How do we identify conflicting articles in a large knowledge base?**
Group articles by topic and manually review only the groups with more than one article. You can also ask the agent the twenty most common questions and check which sources were pulled – conflicts are immediately evident when two articles with differing answers appear.

**Are PDFs and Word documents suitable as source material?**
Less ideal than a structured article, but possible if the document is divided into sections with clear headings. A scanned document, presentation, or a file with complex tables are problematic sources. It's better to extract the relevant content from them into a dedicated article.

**What's the right structure for an article intended for an AI agent?**
Use a question or scenario as the title, provide a concise answer in the first paragraph, and then elaborate in sections with subheadings. Place eligibility conditions and exceptions in a separate section, not embedded within a sentence. This structure also benefits human readers, so there's no compromise here.

---

## Agentforce AI Governance: Accountability, Risk & Controls Model
URL: https://hpi.pro/en/insights/agentforce-ai-governance
AI governance often fails at both extremes: a committee that blocks every initiative, or a lack of controls uncovered during an audit. This guide presents a tiered risk model outlining who approves what, essential controls at each level, truly necessary documentation, and how to maintain agility without sacrificing accountability.

## The Short Answer

Effective AI governance isn't just another layer of approvals; it's a mechanism that quickly answers recurring questions: who decides what an agent can do, what mandatory controls are needed based on risk level, and what's required to change behavior after deployment. Without such a mechanism, every new agent becomes a debate from scratch.

The core principle is tiered classification. An internal agent that only reads information and writes nothing shouldn't go through the same approval process as an agent that interacts with customers and issues refunds. A one-size-fits-all approach either creates bottlenecks or encourages workarounds, and usually both.

## Risk Classification: The Foundation for All Other Decisions

| Tier | Characteristics | Approvers | Mandatory Controls |
| --- | --- | --- | --- |
| Low | Internal, read-only, no sensitive customer data | Process Owner + Platform Manager | Approved grounding, conversation logs, monthly review |
| Medium | Internal with reversible write actions, or customer-facing information disclosure | + Architect + Data Representative | Test set, Persona testing, weekly monitoring |
| High | Customer interaction, financial transactions, irreversible permissions or data | + Risk, Legal, and CISO | Human approval, full audit trail, rollback plan |
| Forbidden | Decisions with direct legal or regulatory implications without human oversight | - | Use case rejected or split into lower-tier sub-tasks |

Classification is determined by only three questions: Is the action reversible, who is exposed to the outcome, and what type of information is involved in the process? Three questions that can be answered in ten minutes, which is precisely what makes this model practical.

## Three Roles to Appoint

The Business Owner is accountable for the outcome, defines what the agent is allowed to do, and resolves conflicts. This is the person who will need to explain to management why the agent answered the way it did, so this role cannot be left vacant or split between two managers.

The Technical Owner is responsible for implementation, monitoring, the change process, and cost. They maintain the agent registry and the runbook for incident management.

An Independent Auditor – typically a representative from Risk or Information Security – is not involved in development and can therefore provide an unbiased review. Their role is to sample conversations, verify that stated controls are actually functioning, and escalate findings to the decision-making forum. Without an impartial party who isn't invested in the project's success, oversight becomes self-reporting.

The responsibility model with Salesforce and model providers is detailed in [Agentforce Security and Shared Responsibility](/en/insights/agentforce-security-shared-responsibility).

## Agent Registry

This is the one document you absolutely cannot skip. It doesn't need to be a system—a maintained spreadsheet is sufficient—but it must be up-to-date. For every active agent: its purpose in one sentence, Business and Technical Owners, risk tier, active channels, a list of Actions and their permissions, grounding sources, human approval points, last review date, and the three main KPIs.

The registry solves a problem that emerges in the second year: agent sprawl. When every team builds its own agent, you find three agents answering the same question in three different ways, and nobody knows who approved the third one.

## Post-Launch Change Process

Distinguishing between routine and material changes is what prevents paralyzing governance. A routine change – wording edits, correcting a response phrasing, adding an existing Knowledge article to the index – goes through the platform's standard change process. A material change requires re-approval at the appropriate tier.

Four changes are always material: adding a new Action, expanding a permission, opening a new channel, and removing or softening a human approval point. These are precisely the changes that are quietly made under pressure to improve performance, so they need to be flagged in advance.

The monitoring mechanisms that feed the change process are detailed in [Observability for AI Agents](/en/insights/agentforce-observability).

## What Governance Actually Reviews, Quarterly

The quarterly review isn't a status presentation. It examines five things: whether the agents in the registry are still necessary, whether the stated controls are functioning through sampling, whether the cost relative to the outcome is justified, what recurring escalations indicate a content gap, and whether material changes followed the correct process.

The review's outcome is a list of decisions: expand, reduce, suspend, or decommission an agent. Governance that cannot decommission an agent isn't governance—it's documentation.

## Scenario: A Retailer Regained Control Without Halting Development

A retail chain discovered seven concurrent AI initiatives across four departments, without a registry and unknown to Risk. The first proposed response was a blanket freeze until a policy could be established—a move that would have also halted the two initiatives already delivering value.

Instead, a two-week mapping exercise was conducted: each initiative was classified by risk tier. Five were found to be low-tier and continued with expedited approval from a Process Owner and Platform Manager. Two—one involving customer refunds and the other exposing inventory data to suppliers—were moved to the high-tier, received human approval points, and were reviewed by Risk before proceeding.

Six months later, the number of initiatives had grown, but management knew for the first time what existed, who was responsible, and what the cost was. The practical conclusion: governance gained legitimacy precisely because it didn't block the low-tier initiatives.

## Governance Risks and Preventative Actions

| Risk | How it Appears | Preventative Action |
| --- | --- | --- |
| Blocking Committee | Teams build outside the approved channels | Fast-track for low-tier with only two approvers |
| Outdated Registry | Auditor discovers an unknown agent | Registry update as a condition for release |
| Ownership only in IT | No one to decide on business behavior | Appoint a named Business Owner for every agent |
| Self-Reporting Controls | Controls exist on paper but not in reality | Conversation sampling by an uninvested party |
| Quiet Material Change | Human approval removed to improve response time | Closed list of changes requiring re-approval |

## Governance Metrics

| Metric | What it Reveals | Frequency |
| --- | --- | --- |
| Registry Coverage | Percentage of active agents documented | Monthly |
| Average Approval Time | Whether the process has become a bottleneck | Monthly |
| Sampling Findings | Gap between declared control and actual state | Quarterly |
| Material Changes Following Correct Process | Process discipline | Quarterly |
| Agents Suspended or Decommissioned | Whether governance can say no | Quarterly |

When guidance is needed to establish a governance model tailored to your organization's size and applicable regulations, the [Agentforce and AI Services](/en/agentforce-ai) is the practical path forward.

## Governance Setup Checklist

- ☐ Risk classification model with three questions approved
- ☐ Approvers set for each tier, including a fast-track for low-tier
- ☐ Business and Technical Owners appointed for every existing agent
- ☐ Independent auditor appointed, not involved in development
- ☐ Agent registry established with all mandatory fields
- ☐ Closed list of material changes defined
- ☐ Quarterly review routine established with authority to decommission an agent
- ☐ Governance metrics defined with reporting frequency to management

### Questions and answers
**Do we need a separate AI committee, or can we leverage existing forums?**
For most organizations, it's more effective to expand an existing forum—like a change management or architecture committee—by adding a Risk representative and a Legal representative for AI discussions. A separate committee often meets monthly, becoming a bottleneck that teams then work around.

**Who owns an AI agent: Business or IT?**
The business process owner owns the outcome and dictates what the agent is authorized to do. IT owns the implementation, monitoring, and stability. When ownership remains solely with IT, critical behavioral decisions go unmade, and the agent often stagnates at its initial version.

**Does every change to an agent's instructions require approval?**
No. Minor wording changes for a low-risk agent can follow standard change processes. However, changes that expand permissions, add new 'Actions,' open a new communication channel, or remove human approval points are material changes requiring re-approval at the appropriate governance level.

**What essential information should be included in agent registration?**
For every active agent: its purpose (one sentence), business owner, risk classification, communication channels, a list of 'Actions' and their permissions, grounding data sources, human approval points, last review date, and performance metrics. This is the first document any auditor will request.

**How can we prevent governance from slowing down AI development?**
Establish a fast track for low-risk agents: a read-only agent for internal use, approved by the process owner and platform manager, without committee involvement. As risk increases, add more approvers and controls. Applying a uniform approval process for all agents is the primary reason governance is often bypassed.

---

## Salesforce Lead-to-Cash: Crafting Your Sales Process from Lead to Order
URL: https://hpi.pro/en/insights/salesforce-lead-to-cash
The Lead-to-Cash process often breaks down at three critical junctures: lead-to-opportunity, opportunity-to-approved quote, and quote-to-ERP order. This guide details essential configurations for each stage, how to determine pricing residency, and why discount approvals frequently become the true bottleneck.

## The Short Answer

Lead-to-Cash is a process that spans four groups – Marketing, Sales, Finance, and Operations – and therefore breaks down at the boundaries, not in the middle. The three transition points that determine everything are: when a lead becomes an opportunity, when a quote becomes approved, and when a closed-won opportunity becomes an order in the operational system.

For each of these, three questions need written answers: who decides, what is required to pass, and what happens if the transition fails. If even one of these is missing, a workaround spreadsheet emerges, and from it stems most of the discrepancies between what was sold and what was billed.

## Transition Point 1: From Lead to Opportunity

This boundary determines the quality of the entire pipeline. The common failure is to automatically convert every lead, which inflates the forecast and renders conversion history useless.

What's required: Written conversion criteria (authorized contact, articulated need, timeframe), defined owner for each side of the boundary, and a rule for handling leads that don't meet the criteria – Nurture, not deletion. Further details on this topic can be found in [Sales Cloud Implementation](/en/insights/sales-cloud-implementation).

## Transition Point 2: From Quote to Approved Quote

This is where most of the process delay concentrates, almost always due to undefined approval hierarchies rather than the tool itself.

| Component | What Must Be Defined | What Happens Without It |
| --- | --- | --- |
| Catalog and Price List | Single source of truth for pricing | Quotes with manual prices |
| Discount Threshold | Tiered structure by percentage and customer type | Every discount goes to the CEO or none at all |
| Approval Response Time | Defined target, e.g., one business day | Phone bypass and retroactive documentation |
| Non-Price Terms | Payment terms, warranty, SLA | Commitments that don't reach Finance |

The last point is usually neglected: organizations build meticulous discount control but allow representatives to commit to net +90 payment terms without any approval.

## Transition Point 3: From Closed-Won Opportunity to Order

This is the most technical point and also where failures are most costly. Three questions determine the architecture:

1.  **Who issues the order** – typically the ERP. Salesforce sends a request and receives an identifier, not managing inventory or billing.
2.  **What happens on failure** – a visible status on the opportunity, an alert to the process owner, and an idempotent resubmission mechanism that won't create a duplicate order.
3.  **What is sent back** – at minimum, an order ID, delivery status, and billing status. Without this feedback, sales reps call Finance to answer customers.

Principles for designing the integration itself are detailed in [Salesforce and ERP Integration](/en/insights/salesforce-erp-integration), and error handling in [Handling Errors in Integrations](/en/insights/salesforce-integration-error-handling).

## The Quiet Problem: Product Alignment Between Systems

Most discrepancies between quotes and invoices aren't due to price but to products. An item code existing in the ERP but not in Salesforce, a product discontinued on one side but remaining active on the other, or a different unit of measure.

The rule: The product catalog is owned by only one side – typically the ERP – and synchronized to Salesforce at a defined frequency, including marking discontinued products instead of deleting them. Deletion breaks historical opportunities and skews analytics.

## What to Measure

| Metric | What It Reveals |
| --- | --- |
| Average Quote Approval Time | Most common bottleneck |
| Rate of Re-created Quotes | Sign of unclear pricing or incomplete catalog |
| Order Creation Failures | Integration stability |
| Discrepancy Between Opportunity Amount and Invoice Amount | End-to-end process quality |
| Closed-Won Opportunities Without an Order within 48 Hours | Leads that fell between systems |

The last metric is the simplest check for process health, and few organizations monitor it regularly.

## Implementation Order

First, implement one end-to-end sales path – one customer type, one product category – until a successful order is created in the ERP. Only after this path is stable should configurations, currencies, legal entities, and renewals be added. Premature expansion solidifies pricing decisions before they are field-tested.

## Summary

Lead-to-Cash is not a technology project but an agreement between four groups on three boundaries. Those who define these boundaries in writing – including failure paths – get a measurable process; those who start with the tools get a chain that works in demos and relies on phone calls in practice.

### Questions and answers
**Is CPQ essential for effective Lead-to-Cash management?**
Not always. Standard product catalogs and Price Books suffice for simple pricing models. CPQ becomes vital for complex configurations, quantity-based tiers, renewals, or subscription pricing.

**Where should pricing reside – in Salesforce or your ERP?**
List prices can exist in both, but only one system should be the single source of truth, feeding the other. Duplicated pricing efforts across systems often lead to discrepancies between quotes and invoices.

**What happens when an order fails to process in the ERP?**
A defined failure path is crucial: clear order status, automated alerts to the process owner, and the ability to re-submit without creating duplicates. Without this, closed deals can disappear between systems.

**Who should approve discount exceptions?**
Implement an approval hierarchy based on thresholds and exception types, with defined response times. Approvals stalled for more than one business day often lead to workarounds, compromising control.

**Do I need an Order object in Salesforce?**
If your ERP generates the final order, reflecting its status and ID in Salesforce is often sufficient. A full Order object is justified when a deal involves multiple orders, partial deliveries, or renewals managed within the CRM.

---

## Sales Cloud Forecasting & Dashboards: Build a Pipeline You Can Trust
URL: https://hpi.pro/en/insights/salesforce-forecast-dashboards
If your sales manager is still forecasting with a separate spreadsheet, the problem isn't the dashboard. A reliable forecast hinges on four prerequisites: a sound hierarchy, clean close dates, agreed-upon categories, and a consistent review cycle. This guide explains how to establish these fundamentals and what to measure to ensure your forecast truly improves.

## The Short Answer

Forecasting isn't a dashboard output; it's a result of data discipline. If deals are updated only once a week, the evening before a pipeline review, no report design will produce a reliable picture. Therefore, effective forecasting starts with four operational prerequisites, and only then moves to visualization.

The clear sign these conditions aren't met is easy to spot: a parallel forecast spreadsheet exists. As long as it does, the organization itself declares the system isn't the single source of truth.

## The Four Prerequisites

| Condition | What's Required | What Happens Without It |
| --- | --- | --- |
| Proper User Hierarchy | A Role Hierarchy that reflects the actual sales structure | Incorrect forecast rollup to the manager level |
| Clean Close Dates | A rule prohibiting close dates older than one week | Forecast includes dead deals |
| Agreed-Upon Categories | Written definitions for Pipeline, Best Case, Commit | Each manager interprets differently |
| Regular Review Cycle | Weekly system-based meeting | Retroactive updates before meetings |

The fourth condition drives the first three. The moment meetings are conducted from the screen instead of a spreadsheet, reps update their deals because otherwise their opportunities won't be visible.

## Forecast Categories: Where Human Judgment Lives

A common confusion arises between probability and category. Probability is derived from the stage and used for weighted calculations – it's statistics. A category is an individual's commitment statement.

A proper separation looks like this: The stage determines an automatic probability that no one can override; the account manager classifies the deal as Best Case or Commit based on their client knowledge; and the team manager can change the classification during a review, with documentation. This yields two numbers with different meanings – a statistical projection and a management commitment – instead of one ambiguous number.

The definition of the sales stages themselves, from which probability is derived, is detailed in [Sales Cloud Implementation](/en/insights/sales-cloud-implementation).

## Three Dashboards, Not Thirty

An abundance of dashboards is a symptom that no one trusts the existing ones. The structure that works:

1. **Executive Forecast** - A single number for the quarter, segmented by category, compared to target, and with a weekly trend. No detailed deal breakdown.
2. **Team Management Pipeline** - Deals by stage and age, highlighting exceptions: stagnant deals, past-due dates, changed amounts.
3. **Rep Work List** - What requires action today. Not a report, but a work queue.

The simple test: if two dashboards display the same number with different values, at least one is superfluous or incorrect.

## Measuring Forecast Accuracy

This is the metric most organizations don't measure, and therefore don't know if they've improved:

- **Commit Variance** - The gap between the Commit amount at the start of the quarter and the actual result. Variance above 20% indicates a loose Commit definition.
- **Forecast Stability** - How much the forecast changed from week to week. High volatility indicates late updates, not a dynamic market.
- **Slippage** - Deals pushed to the next quarter. A high rate indicates weak stage criteria.
- **Accuracy by Rep** - Reveals who systematically inflates and who is conservative, allowing for personalized correction instead of a blanket correction factor.

Complementary adoption metrics are listed in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## The Recurring Mistake: Building a Report Instead of Fixing a Process

When the forecast is inaccurate, the common reaction is to ask for more cuts – by product, by region, by source. This creates reporting overhead and obscures the underlying cause. If 30% of deals have past-due dates, no segmentation will help.

The correct sequence: fix data quality, establish the review cycle, measure accuracy for a quarter, and only then consider additional cuts.

## Summary

A reliable forecast is a byproduct of management routine supported by the system, not a forecasting tool. Three questions determine if you've achieved this: Is a parallel spreadsheet in use? Does everyone agree on what goes into Commit? And does anyone measure historical forecast accuracy? Three good answers are worth more than any dashboard enhancement.

### Questions and answers
**Why does the CRM forecast differ from my sales manager's forecast?**
Almost always, it's due to an undefined 'Commit.' Managers include deals based on customer relationships, while the system calculates based on the stage. The solution is a written definition of what constitutes a 'Commit' and who has the authority to move deals.

**Should I use automated probability or a rep's judgment?**
Both, but keep them separate. Probability is derived from the sales stage and used for weighted calculations; human judgment is reflected in the forecast category. Blending them – a rep manually overriding percentages – invalidates both.

**How many dashboards do I need?**
Typically, three: an executive forecast, a pipeline for team management, and a work list for individual reps. Too many dashboards lead to conflicting versions of the same metrics.

**What do I do with opportunities whose close dates have passed?**
Enforce a strict operational rule: any opportunity with a close date older than one week requires an update or must be moved to 'Closed Lost.' Without this, any forecast calculation is based on inaccurate data.

**How long until I see accuracy improvements?**
Generally, after two to three full sales cycles. This is the minimum time needed to accumulate enough opportunities managed under the new guidelines to compare forecasts against actual results effectively.

---

## Service Cloud Omni-Channel & SLA: Strategic Routing & Capacity Planning
URL: https://hpi.pro/en/insights/service-cloud-omnichannel-sla
Omni-Channel often falters not in routing configuration, but in capacity modeling. When chat, email, and phone are weighed equally, agents become overwhelmed or idle. This guide explains how to define work weights, integrate Entitlements with Routing, and proactively identify when your model can't handle demand.

## The Short Answer

Omni-Channel isn't a distribution mechanism; it's a capacity model. At any given moment, it asks one question: how much work can this agent handle right now? If the answer to that question is incorrect—perhaps because chat and email are assigned the same weight—then routing will function exactly as configured but will negatively impact service.

Therefore, the correct workflow is: first, define the capacity model and weights, then skills, then Entitlements and Milestones, and only at the very end, escalation automations.

## The Capacity Model: The Determining Factor

Omni-Channel assigns a "work quota" (Capacity) to each agent and a weight to each work item. A contact center that assigns a uniform weight to all channels will experience one of two outcomes: chat agents collapse under heavy load, or agents handling emails appear busy when they are, in fact, available.

A reasonable starting point for calibration:

| Work Type | Characteristic | Recommended Relative Weight |
| --- | --- | --- |
| Phone Call | Fully synchronous | Consumes all capacity |
| Live Chat | Synchronous with short breaks | High, typically 2-3 concurrent at most |
| Email / Form | Asynchronous | Low |
| Case Awaiting Customer | Inactive | Zero - must release capacity |

The last point highlights a common error: a Case awaiting a customer that continues to consume capacity makes agents appear busy when they have no active work.

## Skills: Less Is More

Skills-Based Routing sounds like an obvious improvement, but in practice, it's a frequent source of stuck requests. The more skill requirements added, the higher the probability that no available agent meets all of them.

Three rules to prevent this: define skills only when their absence truly prevents handling; define a Fallback level for each requirement that activates after a defined waiting period; and monthly check how many requests were assigned via Fallback – a high percentage indicates the model doesn't match contact center staffing.

## Entitlements and Milestones: From Commitment to Mechanism

An SLA that only appears in a report is retrospective reporting. Entitlements and Milestones transform it into an active mechanism:

1.  **Entitlement** defines which service level is due to which customer – typically one default and a few contractual exceptions.
2.  **Milestone** defines the measured time points: first response, periodic update, resolution.
3.  **Business Hours** determine when the clock runs and must be configured for each time zone and channel separately.
4.  **Stopped Time** freezes the timer when awaiting the customer – without this, metrics penalize the contact center for customer behavior.
5.  **Milestone Actions** generate alerts and escalations **before** the breach, usually around 75-80% of the time.

The guiding principle: if the first alert arrives after the breach, the mechanism measures but doesn't manage.

Fundamental decisions regarding Case definition and the SLA clock are detailed in [Service Cloud Implementation](/en/insights/service-cloud-implementation).

## How to Tell the Model Isn't Holding Up

Five early signs, before monthly metrics reveal a problem:

-   A high percentage of assignments via Fallback – skills don't match staffing.
-   Requests in the assignment queue for more than a few minutes – lack of capacity or a missing Overflow rule.
-   Agents reporting high load while the capacity report shows availability – incorrect weights.
-   An unusual concentration of SLA breaches at a consistent time of day – a staffing issue, not a routing problem.
-   A high rate of assigned and immediately abandoned requests – agents refuse work that doesn't suit them.

## Ongoing Measurement

| Metric | What It Reveals |
| --- | --- |
| Time in Assignment Queue | Does the model find an agent in time? |
| Average Capacity Utilization | Are the weights realistic? |
| Breaches by Milestone | Exactly where the SLA is broken |
| Rate of Prevented Escalations | Does the early alert work? |
| Breach Gaps Between Channels | Is a specific channel unfairly treated in routing? |

## Implementation Order

Start with one channel, a single Entitlement, and no skills. Calibrate the weights against real-world data for two weeks. Only then, add a second channel and skills. Full deployment on a single day makes it impossible to identify which component caused the overload and usually ends with routing being disabled and a return to manual queues.

## Summary

Omni-Channel is a capacity model, not a distribution model, and an SLA is an alert mechanism, not a report. These two principles determine whether the contact center will operate according to the system or find ways to circumvent it – and the difference becomes apparent by the first week of operation.

### Questions and answers
**How do you determine capacity weight for each channel?**
Measure the actual percentage of focused agent attention each work item requires. Live chat demands nearly full attention, while email is asynchronous. Weights set by estimation often prove inaccurate within two weeks, so plan for regular calibration cycles.

**How many Skills should we define?**
Keep them few and distinct. Too many skills can create scenarios where no agent meets all requirements, leading to unassigned, stuck cases. Opt for foundational skills with a defined fallback strategy.

**Are Entitlements necessary for every customer?**
No. Establish a single default entitlement for most customers. Only create exceptions for customers with genuinely differing service contracts. Duplicating entitlements for every account creates unsustainable maintenance overhead.

**What happens to a case when no agent is available for it?**
An overflow rule with a maximum wait time and backup queue is critical. Without it, cases sit unassigned in the routing queue, silently breaching SLAs unnoticed.

**Can we rely solely on Push Routing?**
Generally, yes, and it's the preferred approach – Pull routing often allows agents to cherry-pick easier cases. A practical hybrid includes Push for most work, with a limited Pull queue for non-time-sensitive tasks.

---

## Salesforce Knowledge in Service Cloud: Building a Trustworthy Resource for Agents & AI
URL: https://hpi.pro/en/insights/salesforce-knowledge-management
Knowledge bases often falter by their second year, not at launch. Articles are written once, left unmaintained, and agents revert to internal chats for answers. This guide outlines a sustainable lifecycle for your knowledge base – encompassing cost, creation triggers, periodic review, and usage metrics. Understand what changes when an AI agent consumes information from the same source.

## The Short Answer

A knowledge base isn't a content project; it's an operational process. The question determining its survival isn't how many articles were written at launch, but what triggers the creation of new articles and the review of old ones. Without these two mechanisms, any knowledge base degrades into a folder of files nobody ever opens.

The simple test for current status: How many Cases were closed this month with a linked article? Below 30% means the knowledge base isn't integrated into the workflow.

## Article Lifecycle

| Stage | Responsible Party | Trigger |
| --- | --- | --- |
| Creation | Agent who resolved the inquiry | Recurring Case without a linked article |
| Approval | Knowledge Editor or Subject Matter Expert | Approval queue with a time target |
| Publication | Editor | Visibility setting: internal or public |
| Review | Defined Owner | Review date or usage data |
| Retirement | Owner | Discontinued product or changed policy |

The stage often skipped is retirement. Old articles aren't harmful as a minority, but once they make up a quarter of the knowledge base, agents stop trusting search results – and that's the point of no return.

## The Trigger for Sustainable Knowledge Base Growth

The effective approach isn't to pre-plan a list of topics, but to let service data dictate it. A simple automatic rule: a case type that has recurred more than five times in a quarter, and whose resolutions aren't linked to an article, gets added to a writing queue.

This ensures the knowledge base reflects actual occurrences, not what was estimated in a planning meeting. An important addition: the agent who wrote an article receives visible credit. Knowledge contributions that aren't recognized anywhere stop after a few weeks.

## Article Structure that Supports Both Search and AI

An article written as a continuous document is hard to quickly scan during a call and difficult for a model to retrieve accurately. An effective structure includes: a title phrased as the customer's question, a short answer in the first paragraph, numbered action steps, separate conditions and exceptions, and tagging for product, version, and validity.

Separating exceptions into a distinct section is crucial: when integrated within the steps, both a stressed agent and a retrieval mechanism struggle to distinguish between the rule and its exception.

## Visibility: Internal vs. Public

The same topic often requires two versions. The internal version includes known limitations, workarounds, and escalation guidelines; the public version only includes what the customer can perform. This separation is managed at the article level, not the knowledge base level, to prevent two diverging knowledge bases.

Before launching a Self-Service portal, ensure the public versions truly stand alone. A portal that directs to incomplete articles doesn't reduce inquiries; it merely shifts them to another channel, usually phone. The operational context is detailed in [Service Cloud Implementation](/en/insights/service-cloud-implementation).

## What Changes When an AI Agent Reads from the Knowledge Base

A knowledge base that agents manage with despite gaps isn't necessarily ready for an AI agent. An experienced agent knows to disregard an old article; a retrieval mechanism does not.

Three additional requirements: no two active articles provide conflicting answers to the same question; every article has a clear validity and source; and it is explicitly defined what can be presented to the customer. An agent quoting an internal article or combining two conflicting sources creates trust damage that is difficult to repair. In-depth coverage on the subject can be found in [Grounding and RAG in Agentforce](/en/insights/agentforce-grounding-rag) and [Knowledge Readiness for Agentforce](/en/insights/agentforce-knowledge-readiness).

## Measurement

| Metric | What it Reveals | Threshold for Review |
| --- | --- | --- |
| Knowledge attach rate | Is the knowledge base part of the workflow? | Below 30% |
| Searches with no results | Real content gaps | Weekly list for writing queue |
| Articles unviewed in six months | Redundant content or not found in search | Over 25% of the knowledge base |
| Time from creation to publication | Is the approval queue a bottleneck? | Over two weeks |
| "Not helpful" rating | Specific content quality | Concentration on one topic |

The list of searches with no results is the cheapest and most accurate source for content planning, and it's almost always underutilized.

## Summary

A successful knowledge base is built from the ground up – from real Cases – and maintained by only two mechanisms: a trigger for creation and a trigger for review. Everything else, including adaptation for use by AI agents, stems from the content being up-to-date and self-consistent.

### Questions and answers
**How many articles are needed to get started?**
Aim for ten to twenty articles covering your most frequent inquiries. A large, pre-written knowledge base often becomes outdated before it's even used, whereas a smaller one, updated from real-world cases, grows more effectively.

**Who should write the articles?**
The agents who handle the inquiries, with an editor who approves and standardizes the content. Writing by an external party tends to produce accurate content that doesn't align with the language agents use daily.

**Can the same article serve both agents and customers?**
Typically, not in its entirety. Different visibility levels are required – an internal section (limitations, workarounds) and a public section. Salesforce Data Categories and Channels manage this at the article level.

**How do you know when an article is outdated?**
Combine a re-review date, usage data, and agent feedback. An article not viewed for six months or marked unhelpful should automatically enter a review queue.

**What's required before an AI agent reads from the knowledge base?**
Clean up conflicting articles, mark validity and source, and define what information can be exposed to customers. An AI agent quoting two conflicting articles can cause greater damage than no answer at all.

---

## Boost Agent Efficiency: Seamlessly Integrate Your Contact Center with Salesforce Service Cloud
URL: https://hpi.pro/en/insights/service-cloud-cti-integration
In contact centers, every second counts. From caller ID to screen pop, how quickly agents access critical customer data directly impacts satisfaction and efficiency. This guide explores key decisions for optimizing your Service Cloud integration: caller identification, screen pop behavior, routing ownership, handling transfers and disconnects, and choosing between Service Cloud Voice and existing CTI adapters.

## The Short Answer

The quality of a CTI connection is measured in three seconds: from the moment an agent answers until they see who is calling, their history, and open records. If caller identification fails, the agent starts every call by asking "Who am I speaking with?" – rendering all other investment in integrated telephony imperceptible.

The central decision isn't which adapter to choose, but **where the routing decision is made**: in the PBX or in Salesforce. This is where most of the risk and cost lie.

## The Key Decision: Who Manages Routing

| Aspect | PBX Routing (CTI Adapter) | Omni-Channel Routing (Voice) |
| --- | --- | --- |
| Decision Source | IVR and PBX rules | Availability and skill in Salesforce |
| Cross-Channel Balance | Phone managed separately from chat and email | Single capacity across all channels |
| Rule Changes | Dependent on telecom provider | Within Salesforce settings |
| Implementation Complexity | Relatively low | High, impacts contact center operations |
| When Suitable | Dedicated call center, mature PBX | Multi-channel contact center with mixed workload |

The problematic scenario is dual assignment – the PBX assigns, and the system reassigns. The result is agents receiving calls while handling chats, and availability metrics that are meaningless. If you choose Voice, you break routing rules from the PBX; if you keep the PBX, you don't enable Omni-Channel for the voice channel.

## Caller ID: A Data Problem Before a Technology Problem

Most Screen Pop failures aren't integration issues but a lack of phone number normalization. The same customer appears as 050-1234567, +972501234567, and 0501234567 in three different systems, causing matches to fail.

What's required before connection:

1.  **Uniform Format** - E.164 as the standard, with conversion at entry, not during search.
2.  **Defined Search Order** - First Contact, then Account, then an open Case by number. The order determines what appears when there are multiple matches.
3.  **Handling Multiple Matches** - A quick selection screen, not guesswork. In enterprise PBXs and for corporate customer main numbers, this is the norm, not the exception.
4.  **Handling Non-Identification** - A rapid creation screen, so the call doesn't end without documentation.

Principles of identification and record merging are detailed in [Deduplication and Record Merging](/en/insights/salesforce-data-deduplication).

## What Happens When the Call Doesn't Flow Smoothly

Edge cases determine whether the contact center trusts the system:

-   **Agent Transfer** - Does the Case transfer with the call, or is a new one opened? A transfer that creates a second Case disrupts both FCR metrics and the customer experience, as they recount their story twice.
-   **Mid-Call Disconnect** - A "call back" rule with a time window is needed; otherwise, inquiries disappear without a trace.
-   **Outbound Call** - Is it logged and associated with a Case? Without this, agent workload data is missing by about a third.
-   **Queue Hold and Abandonment** - Abandoned calls must be available in Salesforce, not just in PBX reports; otherwise, the operational picture is incomplete.

Each of these four scenarios must be written as an end-to-end test case before going live. Only testing a standard call proves nothing.

## Recording, Transcription, and Privacy

Automatic transcription has become readily available and affordable, making the temptation to apply it universally high. Three questions must be answered first:

What is the legal basis for recording and processing; how long is the transcription kept, and who can search it; and is the content used to train models? Transcription is sensitive information – it includes details customers provide orally that they wouldn't enter into a form. Field-level access restrictions and defined retention policies are part of the implementation, not a post-launch task.

## Measurement After Go-Live

| Metric | Why It's Important |
| --- | --- |
| Automatic Identification Percentage | Direct measure of data and connection quality |
| Time to Screen Pop | Above two seconds is perceived as slow |
| Calls Without Associated Case | Reveals documentation gaps |
| Duplicate Cases Opened on Transfer | Reveals continuity failure |
| Queue Abandonment | Indication of assignment failure or staffing issues |

## Summary

A successful CTI connection isn't measured by adapter installation, but by the agent starting the call knowing who is on the line and what's open, and by defining every non-standard scenario – transfer, disconnect, multiple matches – beforehand. The decision on routing location is the first to confirm, as it dictates both the operational model and the cost.

### Questions and answers
**What's the difference between Service Cloud Voice and a standard CTI adapter?**
A typical CTI adapter displays telephony within Salesforce, but call routing remains controlled by your PBX. Service Cloud Voice shifts routing control directly to Salesforce Omni-Channel, enriching call records with transcriptions and detailed call data. The fundamental distinction lies in where the call routing decision is made.

**Why doesn't the screen pop always work?**
Usually, this happens when the caller's number isn't properly normalized—due to international prefixes, leading zeros, or inconsistent formatting between systems. This is typically a data quality issue, not an integration problem.

**What happens if one phone number is associated with multiple customers?**
Implement a short selection screen for the agent instead of a system automatically guessing. An incorrect automatic selection is worse than no identification, as it can lead to documentation being logged against the wrong customer record, causing further issues.

**Is it mandatory to record and transcribe all calls?**
No, and for most organizations, it's not advisable. Blanket recording requires robust retention policies, a legal basis, and stringent access controls. It’s better to start with defined categories for recording and transcription.

**Who is responsible when a call connects but the record isn't created in Salesforce?**
This must be clearly defined in writing before going live. Without a single owner for the end-to-end process, any issue can escalate into finger-pointing between the telephony provider and the CRM team. HPI Pro ensures clear accountability.

---

## Salesforce Champion Network: Building Your Internal Adoption Engine
URL: https://hpi.pro/en/insights/salesforce-champions-network
A Champion who's just a title changes nothing. Discover how to select the right frontline representatives, allocate their time effectively, define their exact role, incentivize them, and prevent your network from fizzling out after just two months.

## The Short Answer

A Champions network serves as the distribution backbone for organizational adoption. Users naturally turn to their colleagues before opening a support ticket, and they trust peer advice more than executive announcements. This network leverages that dynamic instead of fighting it.

However, a Champion without dedicated time, a defined role, and genuine influence on priorities is an empty title. These three elements determine if the network will last a year or fade away within a quarter.

## Who Fits — And Who Doesn't

| Criteria | Why It Matters | Red Flag |
| --- | --- | --- |
| Peer Trust | Determines if they're approached at all | Appointed because they were available |
| Business Process Expertise | Enables correct, not just technical, answers | System knowledge without understanding workflows |
| Genuine Willingness | A voluntary role fosters commitment | Forced appointment by a manager |
| Direct Manager's Support | Determines if there will be time for the role | Verbal agreement only |

A common mistake is choosing the most technical user. They’ll provide precise answers nobody asked for and won’t recognize when the real problem is an illogical process.

## Written Role Definition

Without a written definition, the role is interpreted as "the person who's shown problems." The definition includes four responsibilities:

1.  **Local Support** — First-line response to team questions and documenting recurring issues.
2.  **Feedback Collection** — Conveying roadblocks and needs to the central forum, including things no one is officially reporting.
3.  **Pre-Release Testing** — Participating in UAT and testing changes before release to the team.
4.  **Change Communication** — Verbally explaining what has changed, using the team's language.

Alongside responsibilities, the time allocation is also defined: four to six hours weekly during the launch period. If the direct manager hasn't approved this allocation in writing, the role will disappear at the first sign of pressure.

## The Central Forum is the Core

A bi-weekly 45-minute meeting with a fixed structure: what came from the field, what was fixed from the previous meeting, what's releasing soon, and one open question. The first two items are the engine — a Champion who sees their submitted request implemented and communicated in their name will bring five more requests. A Champion who submitted three requests that disappeared will stop submitting.

The forum also serves as an early warning channel: recurring complaints heard there only reach the Dashboard two months later. The connection to measurement is detailed in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## What Benefits Are Provided

Incentives that work, in order of proven effectiveness:

-   **Influence** — A standing place in determining priorities for the next release.
-   **Early Access** — Seeing changes before everyone else, and the authority to say "not yet."
-   **Executive Exposure** — Presenting findings to management quarterly.
-   **Development** — Funding for Salesforce certification or conference attendance.
-   **Recognition** — Named acknowledgment in updates for any fix resulting from their input.

Monetary rewards are rare and not essential. What kills networks is a lack of influence, not a lack of bonuses.

## The Network's Role in Launch and Routine Operations

In the two weeks following Go Live, Champions are the first line of support in the field, so they receive training a week before everyone else. The structure is described in [Salesforce Role-Based Training](/en/insights/salesforce-role-based-training).

In routine operations, the role changes: onboarding new hires, identifying accumulating friction, and testing changes before release. Here, the network transforms from a launch mechanism into a maintenance mechanism that prevents regression and feeds the fixes discussed in [Salesforce UX Simplification](/en/insights/salesforce-ux-simplification).

## Signs of Decline and What To Do

| Sign | Common Reason | Fix |
| --- | --- | --- |
| Declining forum attendance | Requests aren't implemented | Release two fixes from their list immediately |
| Champion asks to resign | Workload pressure in primary role | Renew the allocation with the manager |
| No new requests | Network has become just a broadcast channel | Open a discussion on roadblocks, not updates |
| All requests from one team | Partial representation | Add Champions in missing areas |

## Measurement

Three metrics suffice: number of issues raised through the network per quarter, their implementation rate, and the adoption gap between teams with an active Champion and those without. This gap is the budgetary justification for the entire program. The network itself is a component within [Salesforce Change Management Plan](/en/insights/salesforce-change-management-plan).

## Summary

Choose based on trust, not technical knowledge; formalize time allocation in writing with the direct manager; hold a bi-weekly forum where requests are genuinely implemented; and reward with influence. A network that feels it is changing the system will last for years; a symbolic network will disappear in a quarter.

### Questions and answers
**How many Salesforce Champions do we need?**
A common ratio is one Champion for every 15-25 users, and at least one Champion per independent team or geographical site. Fewer creates a bottleneck; more makes network maintenance challenging.

**How much weekly time should be allocated to a Champion?**
Allocate four to six hours weekly during the launch period, and two hours thereafter. This allocation must be agreed upon with their direct manager and explicitly deducted from their regular duties. Otherwise, the Champion role will be the first to be neglected.

**Does a Champion need to be a technically advanced user?**
No. The most crucial criteria are peer trust and expertise in the business process. System knowledge can be taught; the social influence within a team cannot be assigned.

**How can we incentivize Champions without a budget?**
Offer executive exposure, genuine influence on the roadmap, company-sponsored training or certifications, and public recognition in updates. Influence on priorities is, in practice, the strongest incentive.

**What do we do when our Champion network fades after two months?**
Examine three key areas: are their requests genuinely implemented, does their direct manager support the time allocation, and is there a regular forum? Network decay almost always results from the communication channel losing its impact.

---

## Boost Salesforce UX: Fewer Fields, Fewer Clicks, More Adoption
URL: https://hpi.pro/en/insights/salesforce-ux-simplification
Every unnecessary field levies a daily tax on your users. Discover a practical approach to streamline Salesforce screens: field usage audits, the 'Three-Click Test,' role-based layouts, and measuring task completion times before and after.

## The Short Answer

An extra five seconds per data entry, multiplied by thirty entries per day, then by one hundred users—that's a full workday lost daily to an overloaded interface. UX simplification is typically the highest-ROI action you can take on an existing system, and it almost always involves deletion, not construction.

Three tools are sufficient: a field usage audit, a three-click test for each key task, and layout customization by role and stage.

## Why Screens Get Bloated

No one designs a screen with 80 fields. It originates from seven years of ad-hoc requests, each seemingly reasonable at the time. Three recurring mechanisms:

-   **The "just one field" request** — seemingly negligible marginal cost, but a huge cumulative cost.
-   **A field remaining after a process changes** — no one is responsible for its removal.
-   **The "just in case" field** — "we might need this for a report in the future."

Therefore, simplification isn't a one-off project but an ongoing practice: every new field request requires specifying a field to be removed, or a clear justification.

## Step 1 — Field Usage Audit

For each core object, create a table with four columns: percentage full over the last 12 months, usage in reports, usage in automations and integrations, and the declared process owner.

| Finding | Interpretation | Decision |
|---|---|---|
| Less than 10% populated, no report usage | Abandoned field | Remove from Layout |
| High population, no report usage | Work no one uses | Consult process owner |
| Low population, required field | Users enter arbitrary values | Remove requirement or change to Picklist |
| High population and report usage | Active field | Keep, perhaps move to front |

The third row is the most dangerous: a required field filled with dummy data pollutes your data and erodes trust.

## Step 2 — The Three-Click Test

For each key task—updating a stage, logging a call, closing a Case—count the number of clicks and screens from the initial intent to completion. More than three clicks for a daily task warrants a fix.

Available tools include: Quick Actions instead of opening a full record, editing from a list, Path with guiding fields for each stage, and components that appear only in relevant contexts. The guiding question is always the same: What is the user here to do, and what's in their way?

## Step 3 — Layout by Role, Not by Object

A uniform screen for all roles is a consolidation of all needs, meaning it's bad for everyone. A sales representative needs eight fields; an operations manager needs five different ones; Back Office needs approval fields that have no place for the first two.

Separation by Record Type and Profile, combined with Dynamic Forms for conditional display by stage, can shrink a 60-field screen to a 12-field relevant screen. Important: conditional display is not a substitute for a business decision about what is needed at all.

## Step 4 — The Home Page as a Work List

The first screen a user sees should answer "What do I need to do now," not display general graphs. A prioritized task list, stuck items, and anomalies requiring attention. This is the daily return that justifies the input, and it's the main factor in restoring adoption—see [Improve Salesforce User Adoption](/en/insights/recover-salesforce-user-adoption).

## Measurement: Before and After

Before the fix, measure the average completion time for three core tasks, by five actual users, with a stopwatch. After the fix, re-measure using the same method. A 30% or more decrease in task time is an acceptable result for a first wave of simplification.

Alongside this, track data quality and the completion rate of core actions, according to [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics). True simplification improves both; if time decreased but quality suffered, a necessary field was removed.

## Objections and How to Address Them

"But the field is needed for a report"—Who produced that report in the last year? "Manager X requested it"—Does the process that justified it still exist? "We might need it in the future"—It can be restored within an hour, and historical data is retained even after removal from the Layout.

These objections are managed within the organizational change process, not as a technical discussion—see [Salesforce Change Management](/en/insights/salesforce-change-management-plan).

## Summary

Conduct a field usage audit, remove abandoned fields, reduce required fields to two per stage, build layouts by role, and convert the home page into a work list. Measure task time before and after—this is the evidence that justifies the next wave.

### Questions and answers
**How can I identify fields that can be removed?**
Run a field usage report: look at the percentage of records populated in the last 12 months, and analyze usage in reports and automations. A field with low population that doesn't appear in any reports or automations is a prime candidate for removal.

**Should I delete fields or just hide them?**
Start by removing the field from the page layout. Keep it that way for a quarter, then consider full deletion. Removing from the layout provides immediate user benefits without risking historical data loss.

**How many required fields are reasonable on a single screen?**
Aim for a maximum of five required fields across the entire process, and no more than two at any single stage. Any additional required fields need a process owner to justify their necessity and identify who consumes that data.

**Does Dynamic Forms solve this problem?**
Dynamic Forms is an excellent tool for conditional display based on a stage or profile, but it doesn't replace sound business decisions. A cluttered screen, even if partially hidden, still indicates an unoptimized process.

**How long does a simplification project typically take?**
Auditing and planning usually take two to three weeks, with the first wave of implementation taking three to four weeks. This is one of the most impactful projects you can undertake in Salesforce, offering an excellent effort-to-impact ratio.

---

## Revitalize User Adoption: Salvaging Salesforce After a Rocky Rollout
URL: https://hpi.pro/en/insights/recover-salesforce-user-adoption
A failed rollout isn't just a training problem. This practical recovery guide covers: diagnosing the root cause of disengagement, critical 30-day fixes, rebuilding trust without a 'relaunch' announcement—and knowing when to streamline your system instead of expanding it.

## The Short Answer

When users abandon Salesforce, it's almost never because "they didn't understand the system." The real reason is that the system demanded more from them than it gave back. Recovering adoption starts with diagnosing the cost users are paying, not by providing more training.

The practical sequence: two weeks for diagnosis, 30 days for noticeable fixes, followed by a regular management cycle driven by data. Training only comes into play after the system is already worth the time invested in it.

## Five Reasons for Abandonment—and How to Distinguish Them

| Reason | Identifying Sign in the Field | Corrective Action |
| --- | --- | --- |
| Data Entry Burden | Long forms, mandatory fields nobody uses | Delete fields, set default values, automate |
| Lack of Data Trust | Everyone maintains shadow spreadsheets | Data cleansing + declared single source of truth |
| Lack of Reciprocal Value | User inputs data but gets nothing back | Work lists, personalized views, alerts |
| Management Not Relying on the System | Weekly review based on external files | Move the forum into a Dashboard |
| Performance and Interface Issues | Slow screens, confusing navigation | Optimize and simplify Layout |

The diagnosis itself takes two weeks: ten conversations with actual users (not user representatives), a one-hour observation of real-time work for three roles, and pulling actual usage data using the approach described in [Salesforce Adoption Metrics](/en/insights/salesforce-adoption-metrics).

## The Rule of Return: What the User Gets in 30 Seconds

This is the central test. Open the main screen for a low-adoption role and ask: what does this user get here that they wouldn't get without the system? If the answer is "nothing, they just enter data"—abandonment is entirely logical.

Returns that actually work: today's task list sorted by priority; complete customer history without searching emails; automatic meeting reminders; a quote form generated with one click. Each saves tangible time and thus drives usage without enforcement.

## The First Wave of Fixes: 30 Days

Choose only five to eight fixes, all noticeable in daily work, all deliverable within a month. Recommended composition:

1. Remove 30-50% of fields from the main form, with evidence that no one uses them.
2. A maximum of two mandatory fields at any process stage.
3. A "My Work Today" view for each primary role.
4. Fix three data quality issues users cite as proof the system can't be trusted.
5. One automation that eliminates repetitive manual work.
6. Optimize the slowest screen.

What doesn't belong in this wave: new features, additional modules, new integrations. Expansion during a trust crisis deepens the damage. The correct direction at this stage is simplification, as described in [Salesforce UX Simplification](/en/insights/salesforce-ux-simplification).

## Rebuilding Trust

Trust doesn't return from an email announcement. It comes back from three recurring patterns: fixes delivered on time as promised, transparency about what won't be done, and credit given to whoever raised the issue.

A simple mechanism that works: an open request list for the entire organization with status, bi-weekly releases, and a short message detailing what was fixed and thanks to whom. Within six weeks, this changes the conversation from "the system doesn't work" to "I submitted a request."

The human network that carries this message is the Champions Network, and its
formation is detailed in [Salesforce Champions Network](/en/insights/salesforce-champions-network).

## The Management Cycle Is the Most Powerful Tool

The biggest factor influencing adoption is what the direct manager looks at. As long as they manage the team from an external file, the system is optional. The moment the weekly Pipeline or Cases review happens from a live Dashboard—updating becomes in the representative's personal interest.

This is a management change that requires Sponsor backing, making it part of the change management plan rather than the technical work plan. See [Salesforce Change Management Plan](/en/insights/salesforce-change-management-plan).

## When to Reduce Instead of Expand

If the system contains unused modules, processes built for theoretical scenarios, and automations nobody understands—the correct step is controlled contraction. Disabling what's not in use reduces cognitive load, shortens screens, and decreases maintenance. Many organizations find that the most significant adoption improvement came from deletion, not construction.

## Metrics for Recovery

Measure only four metrics over the quarter: core action completion rate by role, average time to complete the central process, shadow file usage rate (manually reviewed), and one data quality metric. An increase in the first three without an improvement in the fourth means the system was filled faster, not better.

## Summary

Adoption recovery is a project of friction removal and value return, not a project of persuasion. Diagnose the cost users pay, deliver a noticeable wave of fixes within 30 days, move management into the system, and only then return to training and expansion.

### Questions and answers
**How long does it take to recover adoption after a failed Salesforce rollout?**
Expect initial diagnosis within two weeks, primary fixes implemented over 30 days, and measurable stabilization within one quarter. Rebuilding executive trust generally takes longer—typically two quarters of consistent, positive data.

**Should we announce a 'relaunch' of Salesforce?**
Generally, no. A 'relaunch' often reminds users of past failures and raises expectations prematurely. A quieter, iterative series of fixes that users experience in their daily workflow, followed by communication of the positive results, is usually more effective.

**What do we do when managers continue working in Excel alongside Salesforce?**
Eliminate Excel as a legitimate source for management discussions. As long as pipeline reviews are conducted from a spreadsheet, there's no real incentive for users to update Salesforce. This is a management decision, not a technical one.

**Is replacing Salesforce a better option than recovery?**
Almost never. In 80% of cases, the failure stems from processes, data quality, or the user interface—issues that will likely transfer to any new system. Replacement is only justified when the gap is in core product functionality.

**Who should lead the Salesforce adoption recovery effort?**
A senior business process owner with the authority to drive process changes, not just an IT manager. Most required fixes are business decisions: what to stop requiring, who owns specific data, and what metrics are truly important.

---

## Repair or Rebuild Salesforce? A Decision Framework for Existing Systems
URL: https://hpi.pro/en/insights/salesforce-rebuild-vs-refactor
The decision to repair, refactor, or rebuild Salesforce is often based on gut feelings – which is why the same issues frequently resurface within two years. This guide presents four objective tests, explains why a full rebuild almost always exceeds initial estimates, and outlines a practical path for gradual replacement.

## The Short Answer

The three options aren't on the same continuum. **Repair** addresses a symptom, **Refactor** changes an implementation without altering behavior, and **Rebuild** changes the underlying model. The decision hinges on one question: Is the problem in *how* things were implemented, or in *what* was defined from the start?

If the data model is sound but the pain point lies in complex automations and convoluted permissions, that's a Refactor. If the same object serves three conflicting processes and can't be reported on, that's a root issue, and then Rebuild becomes a consideration.

## Four Decisive Tests

| Test | Points to Refactor | Points to Rebuild |
| --- | --- | --- |
| Data Model | Sound, suffers from an excess of fields | Objects serving conflicting purposes |
| Source of Pain | Performance, duplicated automations | Inability to report or extend |
| Scope of Affected Users | Partial, isolatable | Cross-cutting across all processes |
| Cost of Re-testing | Can test a single area | Every change requires full regression |

Three rows pointing in the same direction are sufficient for a decision. A split among the rows usually means the problem is more localized than it feels.

## Why Rebuild is More Expensive Than Estimated

The typical estimate counts only the reconstruction itself. It almost always skips four elements: historical data migration with all accumulated exceptions, re-building integrations, each of which is agreed upon with a third party, a parallel run period where both systems live, and complete re-training for all users.

In practice, these four often constitute more than half the cost. An organization considering a Rebuild that hasn't priced them is comparing apples to half an orange.

## The Practical Path: Gradual Replacement

Even when a Rebuild is decided, executing it as a "stop-and-replace" project is inherently risky. The path that works is a domain-by-domain replacement:

1. **Build the new model alongside the old** - new objects, without touching existing ones.
2. **Migrate one complete process** - with its users, data, and reports.
3. **Deactivate the old equivalent** - this is the step most organizations delay, which turns the project into a double effort.
4. **Repeat** until the old system is empty.

Step three is the test. A system where both the old and new live in parallel for a full year has increased costs, not reduced technical debt.

## What Must Change Regardless

Both paths fail if the change mechanism remains as it was. Minimal governance – who approves model changes, what mandatory testing is required before deployment, and who owns each domain – is the prerequisite to prevent returning to the same point. Prioritizing the debt itself is detailed in [Prioritizing Salesforce Technical Debt](/en/insights/salesforce-technical-debt-prioritization), and early warning signs in [8 Signs for a Salesforce System Upgrade](/en/insights/salesforce-system-upgrade-signs).

## Summary

The choice isn't between "fixing" and "starting over," but between fixing implementation and fixing definition. In most cases that look like a Rebuild, a sound data model is hidden beneath a decade of automations – and that's cleaned in waves, not with a wipe-out.

### Questions and answers
**When is a Salesforce rebuild truly the right choice?**
A rebuild is appropriate when the data model itself is fundamentally flawed — for example, a single object serving three distinct processes — and its correction inevitably requires a migration. If the core problem lies solely with complex automations, a refactor is significantly more cost-effective.

**Will a new Salesforce Org solve our problems?**
Only if the root cause of the chaos was a complete lack of governance. Without clear change management rules, testing protocols, and definitive ownership, a new Org will likely face the same issues within two years — this time with two parallel systems to manage.

**How long does a significant Salesforce refactor take?**
For a medium-sized scope, plan for three to six months, implemented in waves rather than as a single, monolithic project. Each wave should deliver measurable improvements independently; otherwise, funding may halt prematurely.

**What about ongoing development during a Salesforce refactor?**
Freeze only the specific area currently being addressed, not the entire system. A sweeping freeze creates business pressure that leads to workarounds, and every workaround introduces new technical debt precisely where you're trying to clean it up.

**How do we convince leadership to fund clean-up that doesn't add new features?**
Translate the technical debt into measurable operational costs: support hours, integration failures, and extended timelines for every single change. Debt presented as wasted time, rather than abstract code quality, is much more likely to secure funding.

---

## Prioritizing Salesforce Technical Debt: What to Fix First and Why
URL: https://hpi.pro/en/insights/salesforce-technical-debt-prioritization
A hundred-line technical debt list isn't a roadmap; it's a frustration generator. This guide introduces a clear, four-dimensional scoring system, explains which types of debt always take priority regardless of score, and shows how to translate technical debt into a language that secures budget approval.

## The Short Answer

Technical debt isn't measured by code quality but by the cost it imposes on future changes. Therefore, prioritization isn't about "what's ugliest" but **what makes the next piece of work most expensive**.

The quickest sorting rule: An item that causes every change in its vicinity to require extensive regression testing goes first. It multiplies the cost of every other activity in your plan.

## Scoring Across Four Dimensions

| Dimension | Question | Weight |
| --- | --- | --- |
| Business Exposure | What happens if this fails at peak load? | High |
| Frequency | How many times a day is this touched? | High |
| Dependency | How many other areas are blocked because of it? | Medium |
| Effort | How much does it cost to fix in a controlled environment? | Inverse |

Scoring isn't an exact science. Its true value lies in forcing an explicit conversation between those who understand the technical risk and those who feel the business pain – creating an order that can be defended to management.

## Three Types of Debt That Jump the Queue

Regardless of the score, three types always come first:

1.  **Debt that blocks testing** – The absence of a proper Sandbox environment or test data. Any other fix made without it is done in the dark.
2.  **Permissions debt** – A visibility model that has lost all logic is an active regulatory exposure, not an inconvenience.
3.  **Debt concentrated in one person** – When only one person understands a component, the risk is organizational, not technical.

## How to Present Debt to Secure Budget

Management doesn't fund "clean up automations." They fund reduced time and cost. The translation is done in three lines for each item: how many support hours it consumes per quarter, how many days it adds to every change in its area, and what the exposure is if it fails.

Someone who presents "three change requests per quarter, each extended by two weeks due to the same component" gets approval. Someone who presents a dependency diagram does not.

## A Fixed Quota, Not a One-Time Event

The failed pattern: A big cleanup project every two years. The working pattern: A fixed quota of 15%-20% of each wave dedicated to debt, determined in advance and non-negotiable every sprint.

Alongside the quota, at least one prevention rule is required – for example, prohibiting the addition of new automation to an object that already has several, before consolidating them. Without prevention, the rate at which debt is created outpaces the cleanup rate. The connection to development infrastructure is detailed in [Salesforce Sandbox and DevOps Strategy](/en/insights/salesforce-sandbox-devops-strategy).

## Summary

Prioritizing technical debt is an exercise in economics, not aesthetics: fix what makes the next change more expensive, address what blocks testing and what creates exposure, and establish a quota to prevent recurrence. A ranked list of ten items is worth more than a mapped list of one hundred.

### Questions and answers
**How much capacity should we allocate to technical debt?**
Allocate a consistent 15% to 20% of your total capacity per sprint. Fluctuating allocations based on immediate pressure will inevitably fail within two quarters because something more urgent will always arise.

**What technical debt should we avoid fixing altogether?**
Avoid addressing debt in areas slated for replacement or deprecation within the next year, and debt that doesn't manifest in measurable operational costs. 'Cleaning for cleaning's sake' competes for valuable resources.

**How do we measure if our prioritization efforts were successful?**
Success is measured by three key metrics: average time to implement a change request, number of recurring production incidents, and the number of areas requiring full regression testing with each release. Improvement in these areas proves effectiveness.

**What if new technical debt accumulates faster than we can resolve it?**
This indicates a governance issue, not a capacity problem. Without a rule prohibiting new automation on an object before consolidating existing solutions, any cleanup effort will be temporary.

**Is missing documentation considered technical debt?**
Yes, and it carries a high risk, especially when knowledge is concentrated with a single individual. While not visible in reports, it's precisely what makes every change dependent on a specific person's availability.

---

## Boosting Salesforce Performance in Enterprise Environments: Diagnose, Strategize, Measure
URL: https://hpi.pro/en/insights/salesforce-performance-optimization
Slow Salesforce performance is rarely a single root cause, but rather an accumulation of factors: a cluttered UI, non-selective queries, or redundant automation. This guide outlines a layered diagnostic approach (browser, UI, server, data, integration) and introduces key metrics to demonstrate tangible improvements.

## The Short Answer

Poor Salesforce performance is a cumulative symptom: a Record Page with 14 components, three automations running on the same Save, a query scanning a million records, and an integration pulling data during peak hours. The only way to improve without wasting budget is to measure by layers, identify the dominant layer, and address it—then measure again.

## The Five Layers and What to Measure in Each

| Layer | Typical Symptom | Measurement Tool | Common Solution |
| --- | --- | --- | --- |
| Browser and Network | Slowness only for some users | Lightning Usage App per user | Organizational latency, browser version, VPN |
| Screen and Components | High EPT on a key record page | EPT per Page, Debug Mode | Reduce components, lazy loading, Tabs |
| Automation | Slow Save, Timeout on bulk updates | Debug Logs, Flow Interviews | Consolidate Flows, move to asynchronous |
| Data and Queries | Reports crashing, List View stuck | Query Plan, Apex Jobs | Selective filtering, Index, archiving |
| Integration | Load peaks at regular hours | Event Monitoring, API Usage | Bulk API, execution windows, Throttling |

## Working with Large Data Volumes

Above approximately one million records in an Object, the rules of the game change. Data Skew—for example, 200,000 Accounts linked to the same Owner or Parent—creates row locks and slows down any bulk update. The solution is to distribute ownership, not to add hardware, which is beyond your control anyway. Simultaneously, consider archiving: closed records from five years ago that no one reads make every scanning query more expensive.

## Screens: Less is Faster

The average Record Page in an established organization accumulates components at a rate of two to three per year, because every stakeholder requests "just one more widget." Each Lightning component makes its own calls. Two actions yield the most significant gains: moving secondary components to separate Tabs that load only on click, and applying Component Visibility based on Record Type or role, so users only see what's relevant to them. Combining both reduces EPT by tens of percentages without code changes.

## The Action Sequence That Works

Start with a week of measurement without changes to establish a reliable Baseline for five key screens and three key processes. Then, address the screens—this is the cheapest and fastest. In the third phase, consolidate automations by Object, and only in the fourth phase, touch queries and the data model. Integrations are handled concurrently if measurements show them to be the cause.

The logic behind this order is economic: the first layers are cheap and reversible, the later ones are expensive and require regression testing. More details on this topic can be found in [Salesforce Health Check](/en/insights/salesforce-health-check-guide) and [Signs You Need a System Upgrade](/en/insights/salesforce-system-upgrade-signs).

## Common Risks and Preventive Actions

The biggest risk is optimization without a Baseline:
You make ten changes, users still complain, and there's no way to know what helped. Measuring before and after every significant change is a prerequisite, not a luxury.

A second risk is addressing the loudest symptom. The screen most complained about isn't necessarily the slowest—sometimes it's just the one opened most often per day. A third risk is changing automations without test coverage: consolidating Flows is the action with the highest potential for silently breaking business logic.

## How to Measure Success

Four metrics are sufficient: average EPT on the five key screens, Save time for the main business process, number of Timeout and Governor Limit failures per month, and the percentage of queries taking over five seconds. A fifth metric—supplementary and non-technical—is the number of performance complaints in the Service Desk, which should decrease with actual improvements.

### Questions and answers
**Where do we start when users complain that 'the system is slow'?**
Start with data, not guesswork. The Lightning Usage App reveals which screens are slow for specific users, and EPT (Experienced Page Time) for each Record Page points to problematic components. A general complaint without metrics almost always leads to fixing the wrong component.

**What is a non-selective query and why is it critical to understand?**
A non-selective query has filtering criteria that aren't supported by an index, forcing a full scan of a large table. For objects with over a million records, this often results in timeouts or significantly slows down any process relying on it. The solution: filter on indexed fields, avoid NULLs and leading wildcards in LIKE clauses, and request custom indexes when needed.

**When is a Skinny Table justified?**
A Skinny Table is justified when you have a critical report or List View that pulls a few fields from a large object (millions of records) and your filtering is already optimized. This is a request to Salesforce Support, not a self-configuration, and it primarily addresses read performance – not write operations or heavy automation.

**Does replacing Process Builder with Flow improve performance?**
Generally, yes, but not solely due to the tool itself, but rather the consolidation it enables. The true gains come from reducing the number of automations running on the same object and offloading heavy workload to asynchronous processing, not just the migration itself.

**What level of performance improvement can we realistically expect?**
For a focused diagnosis and remediation project, a 30%-50% reduction in loading time for the heaviest screens within six to ten weeks is a realistic target. Greater improvements typically require fundamental changes to the data model or integration architecture.

---

## Salesforce Implementation: The Complete Journey from Discovery to Go-Live
URL: https://hpi.pro/en/insights/salesforce-implementation-guide
Most Salesforce implementations don't fail during development but in between stages: rushing from Discovery to build, migrating without a full rehearsal, or a UAT lacking clear ownership. This guide outlines the complete path, step-by-step, including deliverables and approvals.

## The Short Answer

The core question when implementing Salesforce in an organization isn't "which module to activate first," but rather how to build a roadmap where each step produces an approved outcome, not just another meeting. This guide follows eight stations: Discovery, Solution Design, Iterative Building, Migration, UAT, Training, Go Live, and Hypercare. Each station has a mandatory deliverable, an approver, and a primary risk that needs to be mitigated before moving on.

The central idea is an unskippable sequence: you can't build without an approved Solution Design, and you can't go live without UAT signed off by a business authority. When you skip a station, the problem doesn't disappear—it just moves to a stage where it's more expensive to fix. Further background on the decision to replace an existing system at all can be found in [Replacing a CRM with Salesforce](/en/insights/replace-crm-with-salesforce).

## Complete Stage Map

| Stage | Mandatory Deliverable | Approver | Primary Risk |
| --- | --- | --- | --- |
| Discovery | As-Is/To-Be Document, Baseline, Success Metrics | Business Sponsor & Process Owner | Vague definition of success, only discovered during UAT |
| Solution Design | Data Model, Permissions, ADR, Integration Diagram | Salesforce Architect & CIO | Solution built around a specific request, not a process |
| Iterative Building | Working Vertical Slice each sprint, with Demo | Product Owner | Accumulation of "almost finished" backlog without a clear definition of done |
| Migration | Full Rehearsal Result against Quality Criteria | Data Owner per object | Duplicate or missing data, only found after loading to production |
| UAT | Process Owners' sign-off on End-to-End Scenarios | Business Team Leads | Superficial testing covering only the Happy Path |
| Training | Enablement Plan, Training Materials, Champion List | CRM Manager | Users learning "as they go," leading to poor data quality |
| Go Live | Signed Go/No-Go Checklist and Rollback Plan | Project Management | Going live without a contingency plan in case of failure |
| Hypercare | Daily Incident Log & Adoption Metrics vs. Baseline | CRM Manager & Implementation Team | Project closed too early, before adoption stabilizes |

## Discovery: Before Touching a Tool

The Discovery phase determines everything that follows, yet it's the stage most organizations rush through to "start building already." The required deliverable isn't a presentation but a document that includes a documented As-Is process, a To-Be goal, and an explicit list of what won't be included in the first version. Without such a definition, any new request arriving in two months will be perceived as an "obvious" part of the project.

The most practical tool at this stage is a measurable Baseline: lead handling time, percentage of deals closed without double data entry, rate of empty fields in a customer record. Without a "before" number, it's impossible to prove improvement after launch—only to feel it exists. Organizations that skip this stage return to it anyway, usually in the middle of building, and it costs more. Further implications of early skipping are detailed in [Salesforce Implementation Mistakes](/en/insights/crm-implementation-mistakes).

## Solution Design: Where Most Expensive Decisions Are Made

Solution Design is the stage where choices are made between several possible implementation approaches, and the reasons for choosing one over others are documented. The data model, permissions structure (including sharing between roles and regions), and integration diagram for systems like ERP, payment processing, or marketing platforms—all these must be written before the first development environment is opened.

A common mistake is allowing the development team to "decide as they go" how the Sharing model will look, as it seems like a technical detail. In practice, changing a sharing model after hundreds of records are already in production is a project in itself. Therefore, when the decision spans multiple departments or affects sensitive permissions, it's crucial to ensure that responsibilities and roles around the project are clear—see more in [Salesforce Project Team Roles](/en/insights/salesforce-project-team-roles).

### What Must Be Documented in Solution Design

- Main object and field model, including what is not built in the first version
- Permissions map by role, including exceptions and temporary access cases
- Integration list with data flow direction and sync frequency
- At least three architectural decisions with a rejected alternative and the reason for rejection

## Iterative Building: Vertical Slice, Not a Collection of Screens

In the building phase, the common pitfall is "horizontal" progress—setting up all screens at once without any single process working end-to-end. The correct approach is to build one Vertical Slice per cycle: a complete process, with real data and representative permissions, that can be demonstrated to the process owner for immediate feedback.

Every sprint should end with a demo, not just "code uploaded." When there's no regular demo, a backlog of "almost finished" accumulates, only to be discovered incomplete during UAT, which is precisely what drives up project costs in its last third.

## Migration: The Most Underestimated Part

Data migration is often the biggest project risk, and usually receives the least amount of time in the schedule. It is mandatory to perform a full Rehearsal—loading data to a test environment at full scale, including real volumes, and checking the results against predefined quality criteria: duplicates, missing required fields, date and currency format, and compatibility between systems.

A useful table for managing this risk:

| Quality Check | What is Checked | Recommended Acceptance Threshold |
| --- | --- | --- |
| Required Field Completeness | Percentage of records with critical empty field | Below 2% |
| Duplicates | Customers/Leads with the same business identifier | Below 1% after de-duplication |
| Format Compatibility | Dates, currencies, country codes | 100% compliant with target standard |
| Record Linkage | Parent-Child relationships not broken during transfer | 100% of critical relationships |

## UAT: Testing with Real Ownership, Not Technical Sign-off

Properly conducted UAT involves process owners running end-to-end scenarios themselves, not the project team demonstrating to them. It's recommended to select 8-12 scenarios that cover not only the happy path but also edge cases: a customer without an email address, a deal canceled after approval, a user with partial permissions. UAT sign-off must be explicit—name, date, and a list of gaps remaining open for the next version, not just "verbal approval in a meeting."

## Training: Where the Project Quietly Succeeds or Fails

Even an excellent technical solution fails if users don't adopt it. A good training program includes material tailored to each role (not a uniform presentation for everyone), demonstrations in a Sandbox environment with familiar data, and a list of Champions—lead users from each team who can answer routine questions without opening a support ticket. Organizations that invest in training two weeks before Go Live generally see fewer false positive incidents ("the system isn't working" when it's actually an input error).

## Go Live & Hypercare: Going Live is the Beginning, Not the End

Go Live requires a signed Checklist that includes permissions testing in the production environment, verification of active integrations, and a clear Rollback plan in case a blocking issue is identified. After launch, the Hypercare period begins—typically two to four weeks—during which the team daily monitors error logs, actual usage rates, and user complaints, addressing high-priority issues within one business day. Closing the project before adoption stabilizes is a common mistake: data from the first two weeks almost always presents a worse picture than reality will be after habits settle.

## What Really Goes Wrong in Mid-sized Israeli Organizations

In HPI Pro's practice with mid-sized companies in Israel (20 to 300 employees), most problems don't stem from choosing the wrong product but from process shortcuts:

- **Management unavailable to approve Scope**—The project proceeds based on the IT manager's interpretation, and when management finally sees a result, they request changes that set the project back weeks.
- **Reliance on a single developer or small firm without documentation backup**—When the person leaves, no one understands the decisions made in Solution Design.
- **Migration from unofficial sources**—Excel spreadsheets managed separately by each salesperson, without an agreed single source of truth, making the cleanup stage a sub-project.
- **Cramming UAT into one week before Go Live**—When timelines are squeezed, UAT is the first stage cut, and it's precisely the stage most worth preserving.
- **Lack of language and role-specific training**—Generic English training materials for a sales team working in Hebrew lead to partial use and actual circumvention of the system.

The way to reduce these risks is not to "work faster" but to plan the project's DevOps layer—separate test environments, a defined Release process, and change tracking—from the very beginning. More on this in [Salesforce DevOps Sandboxes](/en/insights/salesforce-sandbox-devops-strategy).

## Checklist Before Moving Between Stages

- ☐ A written deliverable for each stage exists, not just meeting minutes
- ☐ Baseline measured before project start
- ☐ Data model and permissions approved before development begins
- ☐ Each sprint ends with a Vertical Slice demo
- ☐ Full Migration Rehearsal performed with a defined quality threshold
- ☐ UAT signed by process owners with a list of open gaps
- ☐ Role and language-adapted training plan exists
- ☐ Go/No-Go Checklist and Rollback plan exist
- ☐ Hypercare period defined in terms of time and responsibility

## How to Measure Actual Project Success

| Measurement Area | What is Checked | Recommended Tracking Frequency |
| --- | --- | --- |
| Adoption | Percentage of active users vs. total license holders | Weekly for the first month |
| Data Quality | Missing required fields, duplicates | Before Go Live & monthly |
| Process Performance | Lead/deal handling time vs. Baseline | Monthly for the first three months |
| Incidents | Number of support tickets and re-opening rate | Daily during Hypercare period |

Organizations that choose professional guidance throughout this entire journey, from Discovery to Hypercare closure, can leverage [Salesforce Implementation Services](/en/salesforce-implementation) to ensure that each station receives the appropriate deliverable, approval, and risk control before proceeding to the next stage.

## Professional Resources

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Implementation — https://hpi.pro/salesforce-implementation
- HPI Pro – Methodology — https://hpi.pro/methodology

### Questions and answers
**How long does a full Salesforce implementation take for a mid-sized company?**
For a company with 30-80 users and basic sales and service processes, a full journey from Discovery to Go-Live typically spans 10 to 16 weeks. Projects involving complex integrations with ERP or billing systems extend to 20-24 weeks, primarily due to migration and testing.

**What's the difference between Solution Design and standard requirements documentation?**
Solution Design includes a data model, permission map, integration diagrams, and architectural decisions with discarded alternatives. Standard requirements documentation describes what the user wants; Solution Design details how the system will be built to achieve this and the cost implications of each choice.

**Can we skip the UAT phase if we're on a tight schedule?**
It's possible to reduce its scope, but not eliminate it entirely. A minimal UAT involves testing 5-8 critical end-to-end scenarios with actual process owners. Skipping it completely almost always shifts issues to the first few weeks post-Go-Live, when the cost of remediation is significantly higher.

**Who is responsible for data quality during migration from Excel or an old system?**
The professional responsibility for conversion rules and cleansing rests with the implementation team. However, accountability for the business content's accuracy remains with the data owner within your organization. Therefore, we recommend appointing a Data Owner per object to approve migration results before loading into the production environment.

**What actually happens during the Hypercare period?**
Typically lasting two to four weeks, the Hypercare period involves the implementation team providing close support, monitoring error logs and daily adoption, and resolving high-priority issues within one business day. At the end of this period, responsibility is formally transferred to the ongoing maintenance team or internal support.

---

## Salesforce Architecture for Enterprises: How to Design a Scalable System
URL: https://hpi.pro/en/insights/crm-architecture-guide
An organization that continuously adds custom objects, Flows, and point-to-point integrations without a documented architectural layer accrues technical debt. This debt only becomes apparent when attempting to onboarding a new business unit or expand into a new country. This article breaks down Salesforce architecture into six practical layers.

## The Short Answer

Good Salesforce architecture isn't measured by the number of components built, but by an organization's ability to add new business lines, products, or markets without breaking what's already working. The most common problem we encounter isn't poor technology choices, but a lack of documented decision-making layers: who owns each object, why Flow was chosen over Apex, and why there are five separate integrations instead of a single Middleware layer.

This article breaks down architecture into six layers that must be planned together, not in isolation: Data Model and Objects, Sharing and Permissions, Automation, Integrations, Org Strategy, and DevOps with Scalability. Extended background on handling integration errors is available in [Salesforce Integration Error Handling](/en/insights/salesforce-integration-error-handling).

## Data Model and Objects: The Foundation Everything Rests Upon

A common mistake in many organizations: creating a new Custom Object for every business requirement, without checking if an existing object could utilize an additional field or a Record Type. The result after two to three years is an Org with 80-120 custom objects, some with duplicated meanings, and no documentation explaining why each was created.

The guiding principle is to ask before creating any object: who is the business owner, what is the source of truth (Salesforce or an external system), and what happens when a record is deleted or duplicated. Companies managing a complex product catalog, for example, often create a separate Object for each category instead of using Record Types on Product2 – leading to unnecessary maintenance overhead with every upgrade.

A useful table for checking data model maturity:

| Component | Assessment Question | Warning Sign |
| --- | --- | --- |
| Custom Objects | Is there a similar existing Object that can be extended? | Two objects with essentially the same fields |
| Fields | Is the field used for more than one process? | More than 800 fields on a central object |
| Relationships | Was Master-Detail or Lookup intentionally chosen? | Master-Detail chosen "by default" |
| External ID | Does every synchronized object have a unique key? | Synchronization only by name or date |

## Sharing and Permissions: The Layer That Breaks Silently

A lax permissions model isn't immediately apparent – it surfaces when someone sees data they shouldn't, or when a management report shows fewer rows than expected because a Sharing Rule is blocking access. The choice between Role Hierarchy, Organization-Wide Defaults, Sharing Rules, and Permission Sets should derive from the actual organizational structure, not the formal hierarchical structure in the organizational chart.

A common anti-pattern: granting "View All" or "Modify All" at the profile level to "solve" a permissions issue under time pressure, without later narrowing access. This works in the short term and creates broad data exposure in the long term – especially in regulated industries like finance or healthcare. Permission Set Groups allow building modular permissions that can be added and removed without touching the base profile, which is the safer way to handle a growing organization.

Criteria-Based Sharing Rules on objects with millions of records require load testing before Production – there are cases where a seemingly innocuous Sharing Rule causes a recalculation that takes hours and halts overnight processes.

## Automation: Flow vs. Apex

The "Flow or Apex" question is not one of preference but of complexity, volume, and lifespan. Flow is more readable for an operational team, built and maintained quickly, and suitable for evolving business logic. Apex is required for bulk processing of thousands of records in a single transaction, when precise control over execution order relative to other Triggers is needed, or when automated testing (Test Coverage) is required for regulation or formal Change Management.

A common anti-pattern in growing organizations: chains of Flows that call each other (Flow triggering Flow triggering Flow), without a central map showing the execution order. When something breaks, no one knows which Flow ran first. A real-world example: an organization with 14 active Flows on Opportunity, three of them with the same status update logic, written at different times by different people without checking what already existed.

A practical rule of thumb: if there are more than 5-6 branching conditions in a single piece of business logic, or if an external call is required within a loop, Apex is preferable. Beyond that, Flow is better because it's accessible for maintenance even if the original developer has left the company.

## Integrations: From Point-to-Point to a Managed Layer

An organization starting with two external connections (ERP and a payment system, for example) typically builds them directly, point-to-point, which is reasonable at that stage. The problem begins when a third, fourth, and fifth connection are added – each with its own retry logic, error handling, and field mapping, without a shared standard. At this point, any change in a source system breaks one or more connections without anyone knowing in advance.

The transition to a Middleware layer (MuleSoft, or a custom Integration Layer) doesn't have to be a huge project – you can start with the most fragile or most expensive-to-maintain connection and transition gradually. Principles to adopt in any new integration: Idempotency (duplicate calls don't create duplicate records), External ID for reliable identification, and a log that allows precisely reproducing what happened in each call. Further details on integration patterns appear in [Connecting Salesforce to an ERP](/en/insights/salesforce-erp-integration) and [Salesforce Integration Patterns](/en/insights/salesforce-integration-patterns).

## Org Strategy: Single Org, Multi-Org, or Business Unit Segmentation

This is one of the most expensive decisions to change in retrospect. A Single Org with Business Unit Segmentation (using Record Types, Sharing, and Permission Sets for logical separation) suits most organizations because it maintains a single source of truth and unified reporting metrics. Multi-Org is appropriate when business units require fundamentally conflicting authorization models, when a merger or acquisition brings an existing Org, or when actual permissions load impacts performance.

The transition between models after the organization is already built is a heavy project – data merging, re-mapping permissions, and sometimes loss of history. Full details of the decision-making considerations are available in [Salesforce Multi Org](/en/insights/salesforce-single-org-vs-multi-org).

## DevOps and Scalability: How to Maintain Agility

An organization that develops directly in Production, without a proper Sandbox and without CI/CD tools (like Copado, Gearset, or SFDX), quickly reaches a state where every change is risky. A healthy DevOps process includes at least a development Sandbox, a testing Sandbox, version control for Metadata, and an automated Deployment process with regression tests.

Table of key architectural decisions and their long-term implications:

| Decision | Immediate Benefit | Implication in 2-3 Years |
| --- | --- | --- |
| Custom Object for every requirement | Quick solution for a specific need | Org with dozens of duplicated objects, difficult to maintain |
| "Temporary" View All permissions | Solves an issue in minutes | Broad data exposure that is hard to find and close |
| Flow calling Flow | Rapid development without code | Chains that are hard to trace and test |
| Additional Point-to-Point integration | Quick connection between two systems | A network of connections where every change breaks something else |
| Direct development in Production | Saves setup time | High risk for every change, difficulty in recovery |
| Single Org without logical separation | Unified reporting from day one | Difficulty adding a business unit with different needs |

## Example Organizational Scenario

A distribution company with three business units operated on a single Org for four years, with each unit adding its own objects, Flows, and integrations as needed. When management decided to add a fourth unit, it became clear there was no single document explaining who owned each object, and three different integrations synchronized customers to the finance system with conflicting logic.

The architectural team performed a full mapping: they identified 23 objects with no clear owner, six overlapping Flow chains, and two integrations that created duplicate records due to a lack of consistent External ID. The solution wasn't a rebuild, but gradual documentation, consolidating Sharing logic under Permission Set Groups, and migrating critical integrations to a single Middleware layer. Within two quarters, the time to add a new business unit decreased from several months to about six weeks.

## Common Anti-Patterns in Growing Organizations

- **Custom Object for every request** - Creating a new object without checking if a similar one already exists
- **"Temporary" broad permissions** - Granted under pressure and never revoked
- **Flow-in-Flow without mapping** - Automation chains without a central execution diagram
- **Point-to-Point without Governance** - Every new connection built separately without a shared standard
- **Development in Production** - Direct changes without Sandbox, testing, or Version Control
- **Lack of External ID** - Synchronization by name or email leading to duplicate records

## Architectural Maturity Checklist

- ☐ Every custom object has a documented business owner
- ☐ The Sharing model has been tested under realistic data load
- ☐ A central map of all automation chains exists
- ☐ Every integration has an External ID, retry mechanism, and error log
- ☐ A structured Sandbox-to-Production process with regression tests is in place
- ☐ A deliberate decision between Single Org and Multi-Org has been made and documented
- ☐ Governor Limits are checked against a three-year growth projection

When Salesforce architecture requires professional guidance beyond an independent framework, this falls within the scope of [CRM Architecture Services](/en/crm-architecture).

## Professional Resources

- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### Questions and answers
**What's the difference between Flow and Apex when choosing an automation layer?**
Flow is suitable for business logic that changes frequently, involves operational teams, and has fewer than 5-6 complex conditions. Apex is required for complex transactions, loops with external callouts, bulk processing of thousands of records, or the need for automated test classes for regulatory compliance.

**When is it time to move from a Single Org to multiple Orgs?**
Consider multiple Orgs when different business units require conflicting permission models, when permission overhead impacts performance, or during mergers/acquisitions that introduce separate Orgs. This transition is complex and costly. First, evaluate if Business Unit Segmentation or Multi-Currency within a single Org can address the challenge.

**How do you build a Sharing Model that won't collapse under load?**
First, map your organizational structure and user groups. Then, choose between Role Hierarchy, Sharing Rules, and Permission Sets based on the scope of exceptions. Criteria-based Sharing Rules running on millions of records require performance testing BEFORE production deployment, not after.

**What should be done with legacy point-to-point integrations accumulated over years?**
Inventory all existing connections, identify redundant logic across systems, and build a phased migration plan towards a middleware or event-driven architecture. Avoid replacing everything at once; start with the most fragile or highest-maintenance integration.

**How can you ensure the architecture will hold up in three years?**
Assess Governor Limits against projected growth volume, the number of custom objects, the depth of automation chains, and the count of active integrations. An organization with more than 15 triggers on a single object or intertwined Flow chains is an early warning sign.

---

## Mastering CRM Blueprinting: The Essential Deliverables for Your Salesforce Implementation
URL: https://hpi.pro/en/insights/crm-discovery-guide
A well-crafted presentation alone doesn't constitute a true Discovery. A robust CRM blueprinting phase culminates in seven core deliverables, empowering you to build effectively, estimate accurately, and validate rigorously. This guide details each deliverable, defines readiness criteria, and outlines reasonable timeframes.

## What Needs to Be on the Table the Day After Discovery

CRM discovery is measured by actionable deliverables, not by the number of meetings. If, at the end of this phase, the project manager still can't build a work plan, the developer doesn't know which object holds the process, and the data manager doesn't know where the customer originates—the discovery isn't complete, even if the presentation was approved.

This guide defines seven deliverables. Each has a readiness criterion: a single question answerable with a yes or no. Anyone who answers "maybe" to more than two of these is entering the build phase with an identifiable, quantifiable risk. An overview of the post-discovery stages is available in the [Salesforce Implementation Guide](/en/insights/salesforce-implementation-guide).

## Deliverable 1: Decision-Level Process Map

This isn't a flowchart of every click, but a map of decision points: who decides, based on what information, what happens in each branch, and what occurs when no decision is made. Most failures in CRM projects aren't in the main path but in the branches—a frozen deal, a customer returning after two years, or an inquiry opened by the wrong customer.

Readiness Criterion: You can take a real deal from the last month and trace it end-to-end on the map without encountering a gap.

## Deliverable 2: Business Glossary

This is the most underestimated deliverable, and its absence is the most costly. "Customer" means one thing in finance and another in sales. "Active Project" means one thing in operations and another in management. As long as definitions aren't written down, every report sparks an argument.

For each term, the glossary should include: a one-sentence definition, the Salesforce entity representing it, the field that determines its status, and the department that owns the definition.

## Deliverable 3: Decided Core Data Model

During the discovery phase, you don't build a full ERD, but you do decide on four questions that are expensive to change retroactively:

- Whether business activity resides on an Opportunity, a custom object, or a combination, and their relationship.
- Whether an Account represents a legal entity, a physical site, or a buying group—and how hierarchy is managed.
- What is the unique key identifying a customer between Salesforce and core systems.
- Which historical data enters the system and which remains at the source.

Readiness Criterion: You can draw the five main objects and their relationships on a whiteboard without opening a file.

## Deliverable 4: Permissions and Visibility Model

The permissions model is derived from the question of who should *not* see what, not from who *needs* to see what. These two questions seem identical but lead to opposite architectures. A good discovery defines the organizational default for each major object, the extension mechanism, and cases requiring exceptional visibility.

| Question                   | What to Check in Discovery                                   | Why It's Expensive to Change Later                                |
|----------------------------|--------------------------------------------------------------|-------------------------------------------------------------------|
| Object Default             | Private, Public Read, or Read/Write                          | Affects the entire sharing mechanism built upon it              |
| Hierarchy Structure        | Does the role hierarchy reflect management or geography      | Changing requires recalculating access for all records            |
| Cross-Unit Visibility      | Shared teams, manual sharing, or criteria                    | Determines if dedicated logic is needed                         |
| Sensitive Data             | Which fields are restricted and for whom                   | Retroactive changes expose information that has already been viewed |

## Deliverable 5: System Map and Single Sources of Truth

Every central entity must have a single, declared source of truth and a clear synchronization direction. Discovery that leaves two systems "updating each other" creates conflicts that will only emerge in production. The map should also include frequency and tolerance for delay: a sales process can live with a five-minute sync, but credit control usually cannot.

## Deliverable 6: Acceptance Criteria for Core Processes

This connects discovery to testing. Each core process requires three to five acceptance criteria phrased as an observable outcome: "After closing a deal, an order is created in the core system within five minutes, with the same customer ID." Such a phrasing is a requirement, a test script, and a definition of completion. Without it, the UAT phase devolves into a cycle of design comments.

## Deliverable 7: Baseline Metrics Before Change

You can't prove improvement without baseline measurements. During discovery, select three to five metrics and measure them in the current state, even if manually and roughly. The selection of metrics and how to connect them to business value is detailed in the [ROI and Success Metrics Guide](/en/insights/salesforce-roi-kpis).

## Illustrative Example: Private Clinic Network

The following scenario is hypothetical and for illustrative purposes only. A network of eight clinics undertook a CRM project to centralize patient inquiries. During discovery, it was found that two clinics defined "returning inquiry" differently: one counted every call, the other only new topics. This difference seemed semantic but determined whether the system needed one Case object with hierarchy or two separate objects, and it defined all management workload reports.

The team didn't resolve the disagreement in the document. They noted an open decision, assigned ownership at the VP of Operations level, and set a deadline before construction began. The decision was made within two weeks, and the model was built once. Had the decision been postponed, it would have been discovered during UAT—after screens and reports had already been built based on a faulty assumption.

## Warning Signs of Shallow Discovery

- The document describes screens and fields but doesn't describe what happens when a process fails.
- There are no documented decisions for which alternatives were considered.
- All requirements are high priority.
- There is no person's name next to any process, only a department name.
- The number of fields requested on one screen exceeds twenty-five without anyone checking who populates them.

The connection between shallow discovery and subsequent project failure patterns is detailed in the [Common Mistakes Guide](/en/insights/crm-implementation-mistakes), and its impact on timelines is explained in the [Salesforce Project Timeline Guide](/en/insights/salesforce-project-timeline).

## When Replacing an Existing System

When the project replaces a legacy CRM, discovery gains an additional task: deciding what *not* to migrate. A legacy system accumulates fields, automations, and reports that no one uses anymore, and blindly copying them imports old technical debt onto a new platform. The recommended sequence of actions for such a transition is detailed in the [Replacing CRM with Salesforce Guide](/en/insights/replace-crm-with-salesforce).

## How to Know When You Can Start Building

Review the seven deliverables and ask the readiness question for each. If six out of seven answer yes, you can start with a first wave while managing the seventh gap as a documented risk. If three or more answer "maybe," it's better to extend discovery by two weeks than to discover the gap after three months of work have been built upon it.

The natural next step is to translate these deliverables into a wave plan, with an explicit decision on what goes into the first wave and what is consciously deferred.

### Questions and answers
**How long should CRM blueprinting take before a Salesforce project?**
There's no single answer, but a reasonable ratio exists: the blueprinting phase typically accounts for 10-20% of the total project duration. This largely depends on the number of cross-departmental processes and source systems involved. A blueprinting phase that extends beyond this usually isn't due to a lack of time, but rather the absence of an authorized decision-maker to resolve differing opinions.

**What's the difference between CRM blueprinting and a requirements document?**
A requirements document details what users have requested. CRM blueprinting outlines the specific business process that will run, the underlying data model, access permissions, integrated systems, and how its success will be measured. The same requirement can be implemented in five different ways within Salesforce; the role of blueprinting is to choose among them and provide clear justifications.

**Can we conduct blueprinting with the same vendor who will implement the project?**
Yes, and in many cases, it's efficient. The risk is that the blueprinting might lean towards what's easy for the vendor to build. You can mitigate this by ensuring deliverables are provided in a non-proprietary format, architectural decisions are justified with considered alternatives, and the blueprinting phase is priced separately from the implementation.

**What if process owners disagree on process definitions?**
Don't paper over the conflict with vague language. Document it as an open decision with an owner, a target date, and its scope implications, then escalate it to an authorized decision-maker. A blueprint that creates a simulated consensus will lead to expensive change requests later once code has already been developed.

**Do we need to blueprint all processes before starting to build?**
No. You should thoroughly blueprint the processes for the initial phase and map out the remaining processes at a high level to ensure the model isn't blocked later on. The only elements that absolutely must be decided upfront for the entire scope are the core data model and permissions model, as changes to these post-implementation are far more costly than modifying a screen.

---

## 10 Common Salesforce CRM Implementation Mistakes and How to Avoid Them
URL: https://hpi.pro/en/insights/crm-implementation-mistakes
Most CRM project failures aren't technical glitches, but rather critical decisions that were delayed. Here, we've compiled ten recurring mistakes in Salesforce projects, along with early warning signs for each and proactive prevention strategies that are inexpensive when addressed early, but extraordinarily costly after go-live.

## How to Read This List

The following ten mistakes are not ordered by frequency, but by their appearance in a project's timeline. For each, three things are provided: the early warning sign that can be identified in real-time, the preventative action, and the stage after which correction becomes significantly more expensive. The idea is simple — almost every one of these mistakes costs very little if addressed during the correct two-week window.

## 1. Starting with a Feature List Instead of a Process

The Sign: The requirements document is structured as a table of desired capabilities, with no row describing a business outcome.

What Actually Happens: The project produces a system that fulfills the list but doesn't change how work is done. A year later, management asks what has changed, and there's no measurable answer.

Prevention: For each requirement, attach the process it serves and the metric it's supposed to impact. Any requirement without answers to these two questions moves to a waiting list. The set of deliverables that prevents this pattern is detailed in the [CRM Discovery Guide](/en/insights/crm-discovery-guide).

## 2. No Single Process Owner

The Sign: Four people from the same department attend meetings, and none are authorized to say "this is how it will be."

What Actually Happens: Every decision is settled through a compromise that tries to please everyone, meaning two paths are built instead of one. The system becomes twice as complex as necessary.

Prevention: Assign a single individual as the owner for each process. The recommended division of roles is detailed in the [Salesforce Project Team Roles guide](/en/insights/salesforce-project-team-roles).

## 3. Pushing Architectural Decisions to the End

The Sign: The team proceeds with building screens while the question "what is the single source of truth for the customer" remains open.

What Actually Happens: When the decision is finally made, it contradicts what has already been built. Some work is discarded, and the initial project estimate becomes irrelevant.

Prevention: Early on, identify the three to five decisions that are costly to change—core data model, source of truth, permissions model—and set a decision deadline for them before construction begins.

## 4. Importing the Debt of the Old System

The Sign: The migration specification includes all fields from the previous system, including those ending in "_old_2".

What Actually Happens: The new platform is born with two hundred fields that no one maintains, reports relying on unreliable data, and users concluding that the new system isn't serious either.

Prevention: Every field that is migrated must have an owner and a proven use within the last year. The rest go to a readable archive, not into the live system.

## 5. Measuring Progress with Closed Stories

The Sign: The weekly report shows high completion percentages, but no one has yet been able to run a complete end-to-end process.

What Actually Happens: The project looks like a success on the chart until the week before go-live, when it's discovered that all parts work in isolation and no one tested the connections.

Prevention: Define an "first live end-to-end process" milestone as early as possible, even if it covers only one scenario. Until this is achieved, completion percentages are not informative.

## 6. Required Fields as a Substitute for Data Discipline

The Sign: A record creation screen includes twelve required fields, three of which no one knows who is supposed to know their values.

What Actually Happens: Users select the first value in the list to move forward. Reports receive completely full but also completely incorrect data.

Prevention: A field is only required if it's needed for a decision at the point it's requested. Fields needed later in the process are enforced later in the process.

## 7. Building Automation Before the Process Is Stable

The Sign: There are three automation mechanisms operating on the same object, and no one knows their execution order.

What Actually Happens: Unexpected side effects, update loops, and critically, an inability to change a process without fearing what will break.

Prevention: Run a manual or semi-manual process for several weeks before automating it. Automation solidifies a decision — it's best if that decision is the right one.

## 8. UAT Performed by the Builders

The Sign: Test scripts were written by the same team that developed them, and they primarily cover the happy path.

What Actually Happens: The issues that reach production are exceptions — cancellations, credits, duplicate customers, users who left a process incomplete.

Prevention: Testing is performed by process owners, using data similar to real data, with defined responsibility for approval or rejection.

## 9. Training as a One-Time Event

The Sign: The implementation plan includes two workshops in the week before go-live, and nothing afterward.

What Actually Happens: Users learn screens, not processes, forget within two weeks, and turn to colleagues or an Excel sheet. System usage gradually declines unnoticed.

Prevention: Role-based training, as close as possible to when the employee will actually perform the action, with an available support point in the first few weeks.

## 10. No Ownership After Go-Live

The Sign: The project plan has no line item describing who manages the system in the third month.

What Actually Happens: Change requests pile up unanswered, minor bugs become workarounds, and the system quickly becomes outdated.

Prevention: Define operational ownership, a request intake mechanism, and a regular release cadence before go-live, not after. In large organizations, this is typically done through a structured governance model, as described in the [Enterprise Salesforce Implementation guide](/en/insights/enterprise-salesforce-implementation).

## Cost of Correction by Stage

| Mistake | Correction in Discovery | Correction in Build | Correction After Go-Live |
| --- | --- | --- | --- |
| Incorrect Data Model | Diagram change | Object rebuild | Full internal migration and re-testing |
| Lack of Process Owner | Appointment | Stalling and repeated decisions | Maintaining a duplicate process forever |
| Debt from Old System | Field list filtering | Pre-load clean-up | Clean-up on a live system |
| Unnecessary Required Fields | Decision in screen design | Configuration change | Cleaning up accumulated incorrect data |
| Lack of Operational Ownership | Definition in plan | Recruitment or training | Rebuilding user trust |

## Illustrative Example: A Medium-Sized Insurance Company

This hypothetical scenario is for illustration purposes. An insurance company went live with Salesforce for agent management. Three months later, it was found that the update rate of agent records was low. The investigation didn't find a single technical fault: three of the above mistakes were found concurrently — unnecessary required fields on the creation screen, lack of an owner for the agent recruitment process, and training given two months before the first new agents started using the system.

The fix was not technical. Six required fields were removed, a single process owner from the operations department was appointed, and training was split into short segments delivered in the week each group started work. The only architectural change required was deferring the requirement for two fields to a later stage in the process.

## What to Do with This List

Go through the ten mistakes and mark if the early warning sign currently exists in your situation. Three or more signs in a project that has not yet gone live warrant a short pause and correction, not acceleration. The same three signs in a system that is already live justify a structured diagnosis before adding new capabilities atop an unstable foundation.

### Questions and answers
**Which Salesforce implementation mistake is the most expensive to fix?**
Errors in the core data model. Changing the object that holds the primary business process after data has been loaded and automations and reports have been built requires an internal migration, logic rewrites, and re-validation of permissions. User interface errors, on the other hand, are typically resolved in days.

**Does an excessive number of required fields truly impact user adoption?**
Yes, and it's one of the most direct mechanisms. Every required field not essential for a decision adds friction to every record entry. The well-known outcome is inaccurate filler values chosen simply to bypass the screen, which then pollute the very reports for which the field was deemed necessary. It's better to enforce a field later in the process than during initial record creation.

**When are implementation failures typically discovered?**
Usually between the second and fourth month after go-live, once heightened support ends. Until then, users benefit from close guidance, and management observes activity. The true indicator is a sustained decline in record updates alongside an increase in the use of external Excel files.

**Can a Salesforce project that's already live with deficiencies be remediated?**
Almost always, but the sequence of actions differs from a new project. First, stabilize what's disrupting daily work, then clean data, and only then return to re-planning processes. Attempting to fix everything simultaneously while the system is in use usually prolongs the crisis.

**Who is responsible for preventing these mistakes — the organization or the vendor?**
Most are preventable only through collaboration. A vendor can point out an architectural risk, but they cannot arbitrate who owns a process within the organization, what information is considered reliable, or who is authorized to waive a requirement. Failed projects almost always suffer from a lack of an organizational decision-maker with authority, not a lack of technical knowledge.

---

## Salesforce Services: How to Choose Between Discovery, Implementation, Health Checks & Ongoing Support
URL: https://hpi.pro/en/insights/salesforce-services-guide
Many organizations approach a Salesforce partner asking for an "implementation" when what they truly need is a diagnosis or ongoing support. Selecting the wrong service type is a common reason projects go sideways, delivering solutions nobody asked for. This guide maps Salesforce services to your symptoms: what to request in each scenario, expected deliverables, and critical warning signs.

## The Problem Starts With the Order, Not the Execution

When an organization approaches a Salesforce vendor, the first request is almost always "a quote for implementation." In many cases, this isn't the right request. Some organizations already have a system and what they need is a diagnosis; some don't yet know the process they want; and some have a system that works reasonably well but lack ongoing ownership.

Ordering the wrong type of service creates a project that ends with an irrelevant outcome, and this often emerges only months later. This guide maps out four types of services based on the symptom that leads an organization to seek help.

## Quick Mapping by Symptom

| What You Say | What's Likely Needed | Core Deliverable |
| --- | --- | --- |
| "We use Excel and want order" | Discovery then phased implementation | Process map, data model, initial go-live |
| "We have Salesforce but no one uses it" | Health Check and adoption plan | Prioritized findings report and fix order |
| "The system is slow and broken after years" | Technical diagnosis and technical debt plan | Debt mapping, refactor or rebuild recommendation |
| "Our project has been stuck for six months" | Project rescue | Status assessment, go/no-go decision, stabilization plan |
| "We need someone for ongoing maintenance" | Managed Services or support | SLA, release cadence, intake for requests |
| "Our CEO wants to know if Salesforce is a fit" | Brief consultation, not a project | Opinion and suitability recommendation |

This table covers most cases. The rest of the article details exactly what to ask for in each service.

## Service 1: Consulting and Discovery

When to order: When the process, the source of truth, and project scope are unclear; or when there's internal disagreement between departments.

What must be in the deliverable: A decision-level process map, core data model, permissions model, system landscape map, acceptance criteria, and baseline metrics. A deliverable that doesn't include the first five is not a discovery; it's a meeting summary.

Typical scope: Between two and eight weeks, depending on the number of cross-departmental processes. What exactly you should receive and how to identify a good consultant is detailed in the [Salesforce Consulting Guide](/en/insights/salesforce-consulting-guide).

## Service 2: Implementation

When to order: When the discovery is complete, process owners are known, and what goes into the first phase has been decided.

What must be in the agreement: Phased definitions, acceptance criteria for each phase, data migration responsibility, change request mechanism, warranty period, and knowledge transfer plan. The absence of the latter two is the common cause for long-term vendor dependency.

Warning sign: A proposal that details development hours but doesn't specify what "completed" means.

## Service 3: Health Check and Diagnosis

When to order: When the system is live but something isn't working — low adoption, unreliable data, performance issues, or inability to make changes without breaking things.

What must be in the deliverable: A list of findings with severity, business impact, effort to fix, and recommended order. A report listing fifty findings without prioritization is not useful; a report that says "fix these three first and don't touch the rest yet" is a product.

Important distinction: A Health Check is not a remediation project. It's designed to enable a decision on what to fix and in what order.

## Service 4: Support & Managed Services

When to order: When the system is in production and there's no internal team for ongoing ownership.

What must be defined: What's included and what's not. The critical distinction is between fixing a bug, a small configuration change, and developing a new feature. A contract that lumps all three into "a bank of hours" tends to explode within a quarter, because new feature development consumes hours intended for support.

Additionally: Response times by severity, a consistent release cadence, and ownership of documentation.

## Proper Combination of Services

Most organizations don't consume a single service but a sequence. The healthy sequence looks like this:

1. Brief suitability consultation — days, not weeks.
2. Focused discovery for the first phase.
3. Phased implementation.
4. A defined stabilization period after go-live.
5. Ongoing support.
6. Periodic Health Check, preferably not by the original builder.

The sixth point is the most commonly skipped, and it's the cheapest.

## Illustrative Example: Boutique Hotel Chain

This scenario is hypothetical and illustrative. A chain with four hotels approached three vendors requesting a quote for Salesforce implementation to manage events and guest requests. The first two proposals were for full implementation over many months.

The third vendor asked one question: Who defines "event" — the event manager at each hotel or headquarters? The answer was that there was no common definition. In such a situation, full implementation would have created four different systems under one name. The chain instead ordered a brief discovery, received one agreed-upon definition and data model, and only then proceeded to implementation — with a smaller scope than originally proposed.

## Warning Signs When Ordering Service

- The proposal prices hours but doesn't define the deliverable.
- The same proposal includes discovery and implementation in a single amount without a milestone allowing a stop.
- There is no defined warranty period after delivery.
- There's no clause for knowledge transfer and documentation owned by the organization.
- The vendor refuses to provide architectural feedback before signing.

Tools to vet the vendor itself — not just the service — are consolidated in the [Salesforce Implementation Company Selection Guide](/en/insights/choose-salesforce-implementation-company).

## From Order to Document

Once the required service is determined, the next step is to phrase it so that the received proposals are comparable. The structure of the inquiry document and a list of questions to include are detailed in the [Salesforce RFP Guide](/en/insights/salesforce-rfp-guide), and the clauses that should be included in the agreement itself are detailed in the [SOW and Contract Clauses Guide](/en/insights/salesforce-sow-contract-clauses).

## Next Step

Before you request a quote, write down the symptom in one sentence — not the solution. "We lack a unified customer view between sales and service" leads to a different order than "we want Salesforce." This sentence is worth more than any requirements document written after it.

### Questions and answers
**What's the difference between 'Discovery' and 'Analysis' in Salesforce provider proposals?**
In many proposals, the terms are used interchangeably, so focus on deliverables, not titles. A professional Discovery phase concludes with a core data model, security model, system landscape map, and clear acceptance criteria. If a proposal promises 'discovery workshops' without detailing measurable outcomes, you're buying hours, not a foundational document.

**Can I order just a Health Check without committing to further services?**
Yes, and it's often the healthier approach. A Health Check is a standalone service delivering a prioritized findings report. If a provider conditions the check on committing to implementation, it creates a conflict of interest: the same entity diagnosing also sells the cure. It's best to separate the diagnosis from the remediation, at least commercially.

**My organization is small—do we even need external services, or is an Admin enough?**
An internal Admin is sufficient for maintenance, configuration changes, and support. However, they are typically not enough for architectural decisions: core data models, data exposure models, and logical boundaries between systems. The practical rule is to bring in external guidance for decisions that are expensive to change retrospectively, and keep the rest in-house.

**What exactly are Managed Services for a Salesforce environment?**
Managed Services is a model where an external provider is responsible for ongoing maintenance, managing change requests, periodic releases, and monitoring, all within an agreed-upon hour allocation. It suits organizations without a dedicated internal team, but requires precise definition of what's included: bug fixes and minor development are vastly different in terms of cost.

**Can I order all services from a single provider?**
It's possible and common, but it's advisable to separate at least the Discovery phase or periodic Health Checks. The reason isn't mistrust, but inherent bias: a provider who implemented a system may struggle to objectively identify flaws in their own architectural decisions. A second opinion at critical junctures is inexpensive compared to the cost of late-stage remediation.

---

## Salesforce Consulting: When You Need a Consultant and What to Demand
URL: https://hpi.pro/en/insights/salesforce-consulting-guide
A Salesforce consultant is primarily needed when mistakes are costly to fix—not for every technical question. This article defines five triggers that justify external consulting, differentiates a consultant from an architect and admin, and details the deliverables you must receive; otherwise, you've paid for meetings, not solutions.

## When External Consulting Pays Off, and When It's a Waste

A Salesforce consultant isn't needed to answer questions solvable with documentation or the expertise of an experienced admin. They become essential when decisions are costly to reverse, cross departmental boundaries, or when the organization lacks a neutral party to arbitrate.

Five triggers justify external consulting:

1.  **Platform Decision** — Is Salesforce even the right fit, and what are the alternatives?
2.  **Architectural Decision That's Costly to Reverse** — Core data model, single vs. multi-org, source of truth.
3.  **Internal Departmental Disagreement** with no natural arbitrator.
4.  **Stalled Project** requiring a politically un-involved party to diagnose the issue.
5.  **Ahead of a Major Commercial Commitment** — Before signing a multi-million-dollar proposal, an independent opinion is relatively inexpensive.

What doesn't justify consulting: adding fields, building reports, daily operational questions. These are an admin's responsibilities, and consulting that gets pulled into these tasks quickly becomes expensive staff augmentation.

## Three Roles Often Confused

| Role | Question It Answers | Time Horizon | When Hired Incorrectly, You Get... |
| --- | --- | --- | --- |
| Consultant | What's the right thing to do, and in what order? | Months to years | Strategy instead of a solution to a problem |
| Architect | How to implement it without creating debt | The project and system | Detailed design for an undefined problem |
| Admin | How to operate and maintain day-to-day | Weeks | A point solution that solidifies a major decision |

The common pitfall is the third row: an architectural decision effectively made by an admin because it originated as a small request.

## What You Must Get From a Consulting Process

A consulting process that ends with a summary presentation is one you can't act on. The deliverables worth demanding in writing, before signing, include:

-   **Decision Document** — For each decision: the question, alternatives considered, recommendation, rationale, and implications if a different path is chosen.
-   **Assumptions and Dependencies** — What the consultant assumed without verification, and what happens if the assumption is incorrect.
-   **Risk Map** focused on your organization, not a generic list.
-   **Recommended Sequence of Actions** with dependencies, not a wish list.
-   **What Not to Do** — The negative recommendation is often the most valuable part, and it's almost always missing.

The last point is a good quality test: a consultant who can say "don't build that now" is selling a decision, not hours.

## How to Vet a Consultant Before Engaging

The questions to ask aren't about certifications but about their thought process:

-   Describe an architectural decision you recommended and later regretted. What did you learn?
-   In what scenario would you advise against using Salesforce?
-   How do you decide between configuration and development?
-   What do you need from an organization for the consulting engagement to succeed, and what happens if you don't get it?
-   Who in your organization continues to maintain the deliverable after you leave?

A broader set of questions for vetting vendors can be found in our [Guide to Questions Before Choosing a Salesforce Integrator](/en/insights/questions-before-choosing-salesforce-integrator).

## Conflicts of Interest — Not Always Bad, Always Needs Disclosure

A vendor who consults and then implements isn't necessarily problematic; sometimes, it's the most efficient approach because knowledge isn't lost in transfer. The problem begins when the recommendation influences the scope of work for that same party, and there's no balancing mechanism.

Three simple balancing mechanisms:

-   Separate pricing for the consulting phase, not contingent on continuation.
-   The organization's right to issue an RFP after the consulting phase, with deliverables owned by the organization.
-   A requirement that every recommendation be presented with a cheaper alternative and the reason it was rejected.

The third is the most effective and generates the most productive discussions.

## Illustrative Example: Publicly Owned Infrastructure Company

This scenario is hypothetical and for illustration. An infrastructure company considered a large CRM project to manage public inquiries and governmental agency requests. Two vendors proposed an architecture with separate Salesforce orgs for each of the two audiences, citing regulatory information separation.

The external consultant hired reviewed the regulatory requirement itself and found that it mandated access separation, not system separation. This conclusion completely changed the commercial picture: one org with a meticulous exposure model instead of two environments requiring synchronization and double maintenance.

The most valuable deliverable from the process wasn't a recommendation on what to build, but proof that the underlying assumption of both proposals had not been vetted.

## How This Connects to Commercial Decisions

A good consulting opinion changes what you ask of vendors, so it should come before, not after, proposals. From there, the decision moves to two levels: choosing the appropriate pricing model for the remaining level of uncertainty, as detailed in our [Salesforce Project Pricing Models Guide](/en/insights/salesforce-project-pricing-models), and comparing the proposals received, as detailed in our [Guide to Comparing Proposals](/en/insights/compare-salesforce-proposals).

The criteria for vetting the company that will perform the actual work are summarized in our [Guide to Choosing a Salesforce Implementation Company](/en/insights/choose-salesforce-implementation-company).

## Quick Test Before Engaging a Consultant

Answer three questions: What decision do you need to make, who in the organization will approve it, and what will happen if you make it incorrectly? If the answer to the third question is "we'll fix it cheaply later" — you likely don't need a consultant. If the answer is "we'll rebuild" — that's precisely where external consulting pays for itself.

### Questions and answers
**What's the difference between a Salesforce Consultant and a Salesforce Architect?**
A consultant focuses on *what* should be done and in what sequence, incorporating business, organizational, and commercial considerations. An architect focuses on *how* to correctly implement it on the platform: data models, exposure, system boundaries, and technical integrity. In smaller projects, one individual might fill both roles, but for major decisions, two distinct perspectives are often beneficial.

**How long should a Salesforce consulting engagement last?**
Consulting for suitability decisions is usually measured in days. Consulting that accompanies a blueprinting effort is measured in weeks. Consulting that spans months without delivering a concrete decision output is typically staff augmentation, and should be priced and managed as such.

**Can an external consultant work with an existing in-house Salesforce team?**
Yes, and this is often the most effective model. The prerequisite is a clear division of authority: what the consultant decides, what they merely recommend, and who in the organization approves. Without this written clarity, tension arises where the internal team defends what they've built, and the consultant communicates directly with management.

**What should I do if the consultant recommends a solution my internal team opposes?**
Demand that the recommendation be presented alongside the alternatives considered and the decision criteria, not as a final conclusion. Internal team opposition is often based on contextual knowledge the consultant wasn't exposed to. If, after presenting alternatives, disagreement persists, the decision rests with the party holding the risk, not solely on professional correctness.

**How much does Salesforce consulting cost in the US?**
The price is derived from the scope of hours, the consultant's seniority level, and the responsibility they assume for the outcome. It varies significantly between providers. What should be compared is not the hourly rate, but the total cost to achieve the decision: a pricier consultant per hour who finishes in two weeks with a decision document can be more economical than a cheaper consultant who drags on for two months.

---

## Agentforce Readiness: An Organizational Checklist for Data, Permissions, and Processes
URL: https://hpi.pro/en/insights/agentforce-salesforce-ai-guide
Before building your first AI agent, answer a more cost-effective question: Is your organization truly ready? This guide presents a five-axis readiness assessment—Process, Data, Knowledge, Permissions, and Operations—complete with scoring, minimum thresholds for a pilot, and strategies for addressing identified gaps.

## The Short Answer

An Agentforce readiness assessment takes a few weeks; a failed pilot costs months and erodes internal trust. It's therefore worth answering five questions in advance: Is there a defined process with an owner? Is the data the agent will rely on reliable? Is there a maintained knowledge base? Is the permission model clear? And is there someone to operate the agent after launch?

The assessment isn't a yes/no question. It generates a score for each axis and a gap map, allowing for a more precise decision: to proceed, reduce scope, or defer and close a specific gap first.

The decision framework for Use Case suitability appears in [Agentforce for Enterprises](/en/insights/agentforce-for-enterprises).

## Five Readiness Axes

| Axis | Critical Question | Weakness Indicator | Minimum Threshold for Pilot |
| --- | --- | --- | --- |
| Process | Is the process defined and does it have a named owner? | Every team performs it differently, no documented process | One documented process with an Owner and known volume |
| Data | Are the fields the agent will read reliable? | Fields are empty or filled with free text | 90% completeness in critical process fields |
| Knowledge | Is there an approved source for answers? | Old or contradictory articles | 20 updated articles for common scenarios |
| Permissions | Is it clear what each user is allowed to see and do? | Broad and uncontrolled permissions | Mapping of Profiles and Permission Sets to the process |
| Operations | Who monitors, corrects, and approves changes? | No owner after launch | Operational Owner and weekly review routine |

## Axis 1: The Process

The most common failure isn't technological. Organizations choose a process without an owner, and then there's no one to decide on questions that arise during construction: what happens in an exception, when to escalate, what constitutes a correct answer. Without a decision-maker, the technical team invents rules while the business operates with different expectations.

Practical test: Ask four people who perform the process to describe it in writing. If you get four significantly different versions, the process is not ready for agent automation—it's ready for documentation and agreement first.

Volume is also needed. A process that occurs ten times a month won't justify the cost of building and maintenance, even if it's annoying. A good candidate is a process with significant volume, high repeatability, and variation in inquiry phrasing—exactly where rigid rules break down.

## Axis 2: The Data

Perfect data quality isn't required across the entire Org. Quality is needed in the fields the agent will read or update for the chosen process. The assessment is narrow and measurable: take the list of relevant fields and measure completeness, value consistency, and duplicates in related records.

Three tests that provide a quick answer: the percentage of critical fields filled, the number of duplicate records in the central object, and the percentage of cases where the necessary information comes from an external system rather than Salesforce. The third test is surprising—it uncovers a dependency on an integration that wasn't budgeted.

Free text is a particular red flag. When essential information lives in a comments field, the agent will have to infer it, which is precisely where hard-to-trace errors occur.

The recommended order for addressing data gaps is detailed in [Salesforce Data Quality Metrics](/en/insights/salesforce-data-quality-metrics).

## Axis 3: The Knowledge

Knowledge is assessed not by quantity, but by coverage and validity. Take the twenty most common inquiries and check for each: Is there an approved article, when was it updated, and who is the owner? Coverage of half the scenarios with up-to-date articles is better than full coverage with old articles.

An easily overlooked weakness: articles written for internal audiences only that are simultaneously used for customer responses. They may contain phrasing, prices, or exceptions that should not be exposed externally, and this separation must be done before connection.

<h2>Axis 4: Permissions</h2>

The agent operates on behalf of a user, so the existing permission model becomes the AI's security model. If permissions are broad and uncontrolled today, the agent will increase exposure rather than create it. The assessment examines three things: who is authorized to read the data in the process, what write operations are required, and who approves a sensitive operation.

For every action the agent performs, it must be defined whether it is reversible. An irreversible action—financial credit, case closure, sending a message to a customer—requires a human approval point in the initial stage, and therefore affects process design, not just settings.

Planning approval points by risk is detailed in [Human-in-the-Loop in Agentforce](/en/insights/agentforce-human-in-the-loop).

## Axis 5: Operations

An agent isn't a project with an end date. It's a component that requires Traces monitoring, error handling, content updates, and cost control. An organization without someone to do this—even part-time—will see a gradual decline in quality within a quarter.

The minimum: a named operational owner, a weekly review routine for failed calls, an agreed-upon change process for updating Instructions, and a monitored monthly budget. If none of these four exist, the gap on this axis is larger than it appears at the outset.

## Translating the Score into a Decision

| Status | Interpretation | Recommended Action |
| --- | --- | --- |
| All axes at or above threshold | Fully ready | Pilot on one process with Go/No-Go criteria |
| Weakness only in Operations | Can be compensated with support | Pilot with external support and parallel internal capability building |
| Weakness only in Knowledge | Focused content gap | Four to six weeks of Knowledge training, then pilot |
| Weakness in Data or Permissions | Significant risk | Do not start agent; close the gap as a separate project |
| Weakness in three or more axes | Organization not ready | Choose a narrower sub-process and re-assess |

## Scenario: Financial Organization Discovers the Wrong Process Was Chosen

A financial organization requested an agent to handle customer detail change requests. The readiness assessment revealed that the process goes through two external systems, every change requires regulatory approval, and monthly volume is modest. The Permissions and Data axes scored low.

During the same assessment, another process emerged that no one had considered: answering status questions about existing requests. It relied on one reliable field in Salesforce, involved no write operations, and its volume was eight times higher. The pilot was shifted to this process.

The practical outcome of the assessment was not "ready or not ready", but a candidate replacement. This is the main contribution of a readiness assessment—it's cheap enough to run on three candidates and select the one with the fewest dependencies.

## Readiness Checklist

- ☐ A single candidate process with a named owner is chosen
- ☐ Monthly volume and repeatability rate are measured
- ☐ Completeness of critical process fields is checked
- ☐ Duplicates in the central object are checked
- ☐ Dependencies on external systems are identified
- ☐ Knowledge coverage for the twenty most common inquiries is mapped
- ☐ Internal content is separated from customer-facing content
- ☐ Read and write permissions for the process are mapped
- ☐ Reversible versus irreversible actions are classified
- ☐ An operational owner and post-launch review routine are defined

When an external party is needed to conduct the assessment and translate it into a Roadmap, [Agentforce and AI Services](/en/agentforce-ai) is the practical path forward.

### Questions and answers
**How long does a thorough readiness assessment typically take?**
For a medium-sized organization, expect two to four weeks. The first week focuses on mapping the candidate process and conducting interviews, the second on data and knowledge sampling, and the third on permission verification and gap articulation. If it takes longer than a month, it usually indicates that the scope selected for the assessment was too broad.

**Can we start a pilot with a moderate readiness score?**
Yes, provided the known gaps are not in data or permissions. Weaknesses in the operational axis can be mitigated with close support during the initial months. However, an unmaintained knowledge base or unclear permission model will doom the pilot, regardless of the build quality.

**Who should lead the readiness assessment—IT or the business?**
The business process owner should lead, as they will be responsible for justifying the outcome. IT and information security provide input on the data and permissions axes. An assessment led solely by IT tends to focus on platform capabilities rather than evaluating whether the process itself is suitable for automation.

**What should we do if the assessment reveals our organization isn't ready?**
Translate each gap into a roadmap item with an owner and a deadline. Then, choose an alternative candidate process with fewer dependencies. In most cases, there's a narrow sub-process that does meet the threshold, which can serve as the pilot while larger gaps are addressed concurrently.

**Should Agentforce licenses be acquired before the assessment?**
No. The readiness assessment focuses on processes, data, and permissions—all of which exist independently of licensing. Purchasing licenses before identifying a mature use case often leads to unused licenses and pressure to show results too quickly.

---

## Salesforce Health Check: What We Review, When, and Your Key Takeaways
URL: https://hpi.pro/en/insights/salesforce-health-check-guide
A Salesforce Health Check isn't a mere opinion poll; it's an evidence-based diagnosis. We dive deep into your metadata, logs, usage data, and observe real user interactions. This guide details our seven key diagnostic areas, severity rating methodology, and the structure of our deliverables—empowering you to make informed budget decisions.

## The Short Answer

A Health Check is an evidence-based diagnostic process lasting two to six weeks, culminating in three deliverables: a prioritized list of findings by severity, a 30-day Quick Wins plan, and a Roadmap for in-depth investments. What makes it useful isn't the breadth of the scan, but the evidence attached to each finding—a number, a log, or a screen recording—because without it, discussions devolve into debates of opinions.

## Seven Examination Axes

| Axis | What's Actually Examined | Evidence Source |
| --- | --- | --- |
| Process and Adoption | Is the documented process actually being followed? | Login History, Field Usage, User Observation |
| Data Model | Redundant Objects, Unused Fields, Duplicate Relationships | Field Usage, Metadata API, Sample Queries |
| Automations | Overlaps between Flows, Triggers, and old Process Builder | Metadata, Debug Logs, Execution Order Analysis |
| Permissions and Security | Bloated Profiles, Conflicting Sharing Rules, Excessive Access | Security Health Check, Permission Set Assignments |
| Integrations | API Limits, Recurring Failures, Error Handling | Event Monitoring, Middleware Logs |
| Performance | Loading Times, Heavy Queries, Stuck Batch Jobs | Lightning Usage App, Apex Jobs |
| Cost and Licensing | Unused Licenses, Storage, Duplicate Services | Licensing Report, Invoice vs. Actual Usage |

## How Severity is Rated

Arbitrary ratings render a report useless. The method that works: each finding receives two scores between 1 and 5—Impact (what happens to the business if not addressed) and Frequency (how many times per month it occurs). The product determines priority, not an assessment of how "ugly" the code is. A finding with a score of 20 or more is addressed immediately; 12–19 is scheduled for the upcoming quarter; below 12 is noted but not addressed, unless it's cheap to fix while working on something else.

The most crucial distinction in the report is between symptom and root cause. "Users don't fill in the Reason for Loss field" is a symptom; the root cause might be that the field isn't required, the picklist values aren't relevant to the domain, or no one reviews the report based on it. Fixing only the symptom—making the field required—generates bad data instead of missing data.

## What You Get in the End

A valuable deliverable includes a findings document with evidence for each line item, a severity matrix, a 30-day plan where each item can be executed without architectural changes, and a one-to-two-quarter Roadmap with rough effort estimates. Additionally, a Decision Log of three to five critical organizational decisions is required—for example, whether to merge two business units into one Org—because without them, the Roadmap is uncertain.

Further discussion on decisions following the diagnosis can be found in [Rebuild vs. Refactor](/en/insights/salesforce-rebuild-vs-refactor) and [Prioritizing Technical Debt](/en/insights/salesforce-technical-debt-prioritization).

## Common Risks and Preventive Actions

The first risk is a report perceived as an accusation list. If findings are phrased as criticism of an internal team, the organization becomes defensive rather than corrective. Proper phrasing focuses on the current state and ongoing costs, not historical responsibility.

The second risk is a review that concludes without an owner. Every finding must have a person's name and a date; otherwise, the report joins a folder no one ever opens. The third risk is excessive breadth: a diagnosis attempting to cover all seven axes in full depth in two weeks will produce a superficial overview across the board. It is better to choose three axes for in-depth analysis and mark the rest for the next round.

## How to Measure Success

A Health Check is successful if, within 60 days, at least 70% of the 30-day items have been completed, if management has approved a budget for at least one in-depth investment, and if two operational metrics—for example, integration failure rate or central screen loading time—have shown measurable improvement against a baseline established at the beginning of the diagnosis.

## Next Steps

Before ordering a review, it's advisable to prepare three things: a list of critical business processes, read access to logs and metadata, and names of three actual users whose work can be observed. These three items shorten the diagnosis by about a week and significantly improve the quality of findings.

### Questions and answers
**How long does a Salesforce Health Check typically take?**
For a mid-sized organization with a single org, expect two to three weeks. This includes approximately one week for evidence gathering and observation, followed by one week for analysis and reporting. A complex org with multiple business units and dozens of integrations may require four to six weeks. Beyond that, it shifts from an assessment to a full-scale project.

**Do we need to grant full Admin access to an external consultant?**
No, not for most checks. Typically, 'View Setup and Configuration,' limited 'View All Data,' and read-only access to logs are sufficient. If sensitive data is a concern, we work on a refreshed Sandbox and only complement data from Production for metrics that cannot be replicated.

**What's the difference between your Health Check and Salesforce's built-in Security Health Check tool?**
Salesforce's tool assesses security settings against a baseline and provides a score. A comprehensive HPI Pro Health Check also covers processes, data models, automations, integrations, user adoption, and cost implications. Salesforce's built-in tool is just one input to our holistic assessment.

**What's the approach if a finding requires a fundamental rewrite?**
Such findings are not included in the 'Quick Wins' plan. We mark them as a separate investment decision, with estimated effort, the risk of avoidance, and a target date for re-evaluation. These are prioritized independently from urgent root-cause fixes.

**Is a Health Check worth it if our Salesforce system is currently functional?**
Yes, absolutely, in two key scenarios: First, before any significant investment, to ensure you're building on a stable, scalable foundation. Second, after two to three years of accumulated changes, when a comprehensive understanding of automations and permissions often becomes fragmented among your team.

---

## Trademark Disclosure
Salesforce® and Agentforce® are trademarks of Salesforce, Inc. HPI Pro is an
independent consultancy and does not present itself as an official Salesforce
partner unless explicitly stated on the site.