Salesforce Optimization implementation · CloudX
Salesforce optimization: health checks, cleanup and ongoing support for existing orgs
CloudX is an Israeli consultancy that improves and supports existing Salesforce orgs. We start with a health check that maps data, automation, permissions and technical debt, build a prioritized fix plan, deliver it in phases and stay on as your admin and support team. Even a rollout that went wrong can usually be stabilized and improved without starting over. We work with startups, cybersecurity and SaaS companies, nonprofits and foundations, and we specialize in go-to-market processes and ARR measurement tools.
Signs your Salesforce org needs help
Most organizations that come to us are not looking for a new system. They have a Salesforce org that works, just not the way it should. These are the signs we see most often:
- The team works around the system. Reps keep a side spreadsheet, and data reaches Salesforce late or not at all.
- Reports disagree. Marketing, sales and finance show different numbers for the same question, and nobody trusts the dashboard.
- Flow error emails. Failure notices land in someone's inbox, and nobody is sure what they break.
- Duplicates. The same customer appears two or three times, with history split across records.
- Fear of change. Every small change breaks something else, because there is no documentation and nobody knows the org in depth.
- Permissions too wide or too narrow. Integration users running as System Administrator, while reps are blocked from editing their own records.
- The admin left. Processes keep running under a user who is no longer with the company, and their access was never really closed.
- Salesforce notices nobody handles. Expiring certificates, MFA requirements and retiring features.
If three or more of these sound familiar, a health check is the right next step.
What a Salesforce health check covers
A health check is a structured, read-only review of the org that ends with findings and a prioritized work plan. This is the scope we cover:
| Area | What we review | Typical findings |
|---|---|---|
| Data | Duplicates, empty required fields, inconsistent values, matching and duplicate rules | One customer across several records, invalid state and country values that fail flows |
| Automation | Flows, Workflow Rules, Process Builder, Apex triggers and their execution order | Several flows on one object, legacy automation still running, flows with no error handling |
| Security and access | Profiles, permission sets, sharing rules, role hierarchy, FLS, MFA and SAML | Integration users with admin rights, MFA bypass, expired certificates |
| Dependencies and users | Scheduled jobs, OAuth connections, Email-to-Case, alert recipients, outbound messages | Critical processes running under a departed employee's user |
| Technical debt | Untested code, unused fields and objects, retiring features | Legacy SOAP API calls, components nobody can explain |
| Adoption and reporting | Who logs in, what is kept current, which reports are used and what definitions they rely on | Conflicting reports, dashboards nobody opens |
Data
Dirty data is the first reason teams stop trusting Salesforce. We measure duplicates across Leads, Contacts and Accounts, review existing matching and duplicate rules, and build detection by email, domain or name and company. Merging runs through a dedicated tool or a Lightning Web Component and Apex tool we build for it, always with written rules for which record survives and what happens to its history.
Automation
An org that has grown over the years usually has layers: Workflow Rules and Process Builder from the previous generation, flows built by several different people, and sometimes Apex triggers. We map what runs on each object and in what order, find loops and recursion, move legacy automation to Flow, and add fault paths so a failure reaches the right person instead of disappearing. Where possible we convert flows to before-save, which runs faster and does not trigger an extra update on the record.
Security, sharing and FLS
This is where the most sensitive findings sit. We check who sees which records and fields, how sharing rules and the role hierarchy combine, which users can bypass MFA, and which integration users run on a System Administrator profile instead of a minimal permission set on a dedicated Integration license. Then we move access to permission sets and permission set groups and test every role against a real scenario.
Technical debt and adoption
Technical debt in Salesforce is not only code. It is also fields nobody fills in, reports built on definitions that have since changed, and features Salesforce is retiring. In parallel we look at adoption: who actually works in the system, where the team works around it, and what the screens need so that working inside Salesforce is faster than working outside it.
A rollout that went wrong: stabilize instead of starting over
A Salesforce implementation that did not deliver is very common, and it almost never means the system has to go. In most cases the data model is reasonable, and the problem is automation built without a plan, permissions nobody tested, and a process that was never fitted to how the team really works.
Our approach is to stabilize first: stop whatever is corrupting data, fix what blocks daily work, and only then rebuild specific parts. A full rebuild is worth it only when the data model itself blocks the business, and that decision is made on health check findings, not on gut feeling.
How CloudX works: audit, plan, fix, support
- Audit. Read-only access, conversations with key role holders, and a map of data, automation, permissions, dependencies and reports. You receive a findings document written in business language, not only a technical list.
- A prioritized plan. Each finding gets a risk level, an effort estimate and an owner. First whatever could break a critical process or expose data, then what blocks the team, then improvements.
- Fixes in phases. Every change is built in a sandbox, tested, moved through source control and the Salesforce CLI, and deployed with a rollback plan. Sensitive changes, such as deactivating a user or replacing an integration user, get a written change plan and runbook.
- Ongoing support. Once the org is stable we continue as your admin and development team: requests, errors, small changes, improvements and preparation for Salesforce releases.
Salesforce managed services and outsourced admin
Not every organization needs a full-time Salesforce admin, and even organizations that have one sometimes need a developer, an architect or a security specialist. CloudX's admin-as-a-service model gives you access to a whole team, as needed.
What it usually includes:
- User requests: permissions, fields, reports and issues.
- Diagnosing and fixing Flow and Apex errors, down to the root cause rather than a workaround.
- Small changes and builds, from validation rules to Lightning Web Components.
- User management, including safe onboarding and offboarding.
- Tracking Salesforce notices: certificates, MFA, retiring features and releases.
- Ongoing org documentation, so the knowledge stays with you.
When an admin leaves, we map what runs under their user before deactivation and move each item to a new owner following a runbook. Deactivating first often stops processes without any visible error.
GTM, RevOps and ARR measurement
Much of our optimization work is with startups and cybersecurity and SaaS companies, where Salesforce is the system of the go-to-market team. The same problems keep coming back: a lead that is both MQL and SQL, sales stages that can be skipped, close dates that drift on renewals, and sales engagement integration users with full access.
We specialize in building ARR measurement tools inside Salesforce. In an existing org this starts with finding where revenue really lives: contract lines, subscriptions or Opportunity Products. From there we build a scheduled job that writes a snapshot per account per period, classifies every change as new, expansion, contraction or churn, and adds a renewal control that flags renewal dates that do not match the last revenue month. The result is one ARR number that leadership and the board can rely on, with a trail behind every change.
For full GTM implementations, Agentforce and integrations, see our Salesforce implementation page.
AI-assisted quality control
Improving an existing org means knowing in advance what each change could break. That is why we build AI into our quality control, with a person always approving the output:
- An automated QA agent, running in production in our own delivery work. A monday.com status change triggers checks of validation rules, flows, permissions and Apex tests, and the report comes back to the same item.
- Briefings on an unfamiliar org (demo). A Claude skill reads metadata in read-only mode and produces an org profile, a Flow error brief and a change impact brief. In a run on a real org, the error brief found a root cause different from what the error message suggested.
A typical optimization project
- Kickoff. What hurts today, who uses the system, and which notices or issues are open.
- Access. A read-only user in production and sandbox access.
- Health check. Mapping and a findings document.
- Priority workshop. We go through the findings together and decide what to fix first.
- Stabilize. Fix whatever puts data, security or critical processes at risk.
- Improve. Data cleanup, automation consolidation, permissions, screens and reports.
- Document and hand over. Org documentation and a plan for the next phase.
- Ongoing support. Admin as a service, at the level that fits you.
A focused health check usually takes a few weeks, and a stabilization and improvement program typically runs a few months, depending on the size of the org and the number of teams.
What drives the cost
There is no fixed price for Salesforce optimization, because cost follows what the org contains. The main drivers:
- Org size and complexity: the number of custom objects, flows, Apex code and integrations.
- Data condition: how many duplicates there are and how much cleanup and migration is needed.
- Security sensitivity: the number of roles, external portals and regulatory or audit requirements.
- Rebuild scope: targeted fixes versus replacing a whole process.
- Support model: a block of hours, a monthly retainer or a team embedded in your daily work.
The health check itself is the reliable way to get an estimate, because it replaces guesswork with findings.
Beyond the fix: next steps
A stable org is a good foundation to grow on. Many organizations go on to Agentforce and AI agents, to a well-governed NetSuite or ERP integration through Workato, or, for nonprofits and foundations, to improving NPSP or Nonprofit Cloud (Salesforce for nonprofits).
Tell us what is not working in your Salesforce org today. We will tell you what to check first and what a health check would look like for you. Book a conversation.
Work we have done
Several SaaS, cybersecurity and media companies · In production
Safe admin offboarding and integration user cleanup
At several SaaS, cybersecurity and media companies a long-time admin was leaving, and many processes ran under their user. We mapped their footprint in the org: scheduled jobs, OAuth connections, outbound messages, Email-to-Case, dashboards running as them and alert recipients, including 33 alert configuration points in one org alone. Each company received a change plan ordered by urgency and a detailed runbook. At one of them we found that closing the employee's Google account would not block login, because the user had a local password and permission to bypass MFA. At a cybersecurity company we moved a critical daily flow to an active owner, hardened it with fault paths, and moved the sales engagement integration user from a System Administrator profile to a minimal permission set on a dedicated Integration license.
Construction technology company · In production
Fixing flows and permissions on contracts and meeting tracking
Reps were locked out of editing contracts once they were activated, and an intro-meeting outcome flow created attendees without their tracking fields, leaving about 1,360 mismatched rows. We granted contract activation to the relevant sales profiles and added a validation rule that allows two defined fields to be edited on an active contract while locking the rest. We converted the flow that timestamps project contact roles to before-save, and diagnosed the root cause in the meeting outcome flow. The team now works on contracts without opening admin requests, and active contracts stay protected.
Ad-tech company · In production
Restoring the Data Cloud to Marketing Cloud data flow
The Contact, Lead, Account and Opportunity data streams had failed on every refresh for months, and no records reached Marketing Cloud. We found the cause: fields from a feature that had been switched off were still in the stream query. Since they cannot be deleted in a managed data kit, we disabled them in the stream and the data flowed again. In the same engagement we set up an External Client App to move one of the client's integrations from the retiring SOAP API to REST, and handed the details to their developers. The client received plain-language updates throughout.
Higher education institution and B2B organizations · In production
Restoring nightly duplicate merge and domain-based duplicate management
At a higher education institution, accounts sharing an email address, where one lacked an ID number, stopped merging in the nightly automatic merge, and duplicates began to pile up. We unpacked the merge rule logic, explained to the team how it decides, and worked the case with Cloudingo support until the cause was found: a partial reindex. After a full reindex the nightly merge ran successfully again. For B2B organizations we build duplicate detection by email domain across Leads, Contacts and Accounts: a field that extracts the domain, a backfill for existing records, matching and duplicate rules, and a controlled bypass for the integration user.
Cybersecurity and SaaS companies · In production
ARR snapshots and renewal control
GTM teams needed one ARR number, fed consistently by their sales processes. We built ARR automation that writes a snapshot per account per period and records every account-level movement, a flow that opens an opportunity from a prospecting meeting, and a screen flow that requires a structured reason when a deal is closed lost. A report formula compares each renewal date with the last revenue month by month difference, so only genuine exceptions are flagged for review. Leadership sees ARR and movements on the same data the team already maintains.
SaaS company · In production
Security review: SAML, phishing-resistant MFA and SOAP retirement
The company signs in to Salesforce through Google Workspace as its SAML identity provider and received several notices at once: an expired signing certificate, a phishing-resistant MFA requirement and the SOAP API retirement. We confirmed the certificate rotation needed no coordination with Google, identified old certificates and an unused Salesforce-as-IdP setup, and analyzed login history to check which integrations still relied on SOAP. We also flagged a marketing platform integration user running with System Administrator rights. The team received a clear answer and an action plan for every notice.
FAQ
What is a Salesforce health check and what does it include?
A Salesforce health check is a structured, read-only review of an existing org that ends with a findings document and a prioritized work plan. It covers data quality and duplicates, automation (flows, Workflow Rules, Process Builder and Apex), permissions, sharing and FLS, dependencies on users and integrations, technical debt, and adoption and reporting. Each finding gets a risk level, an effort estimate and an owner.
How long does a Salesforce health check take?
A focused health check usually takes a few weeks, depending on the size of the org, the number of automations and integrations, and how many teams use the system. The stabilization and improvement program that follows typically runs a few months and can be delivered in phases without stopping daily work.
Our Salesforce implementation failed. Do we need to start over?
Usually not. In most rollouts that went wrong the data model is reasonable, and the problem is unplanned automation, untested permissions and a process that was never fitted to how the team works. We stabilize first, fix what blocks the team, and rebuild only specific parts. A full rebuild is worth it only when the data model itself blocks the business.
Who provides Salesforce managed services in Israel?
CloudX is an Israeli consultancy providing ongoing Salesforce support to startups, cybersecurity and SaaS companies, nonprofits and foundations, in Hebrew and English. Support covers user requests, diagnosing and fixing Flow and Apex errors, small changes and builds, user management, tracking Salesforce notices and ongoing org documentation.
Outsourced Salesforce admin or an in-house admin?
An outsourced admin fits organizations that do not need a full-time role, or that have an admin but sometimes need a developer, an architect or a security specialist. With CloudX admin as a service you get a whole team as needed, with documentation that stays with you. Organizations with an in-house admin often use us as backup and for projects that need development.
How do you clean up duplicates and data in Salesforce?
We start by measuring how many duplicates exist across Leads, Contacts and Accounts and by which keys (email, domain, name and company). Then we write rules for which record survives, merge through a dedicated tool or a Lightning Web Component and Apex, and add matching and duplicate rules so new duplicates are stopped at entry. Cleaning inconsistent values such as states and countries also prevents flow errors.
How much does Salesforce optimization or ongoing support cost?
There is no fixed price, because cost follows what the org contains: the number of objects, flows, code and integrations, data condition, security sensitivity, rebuild scope and support model (a block of hours, a retainer or an embedded team). The health check is the reliable way to get an estimate, because it replaces guesswork with findings.
How do you migrate Workflow Rules and Process Builder to Flow?
First we map what runs on each object and in what order, including Apex triggers. Then each automation is rebuilt as a flow in a sandbox, duplicate flows are consolidated, flows are converted to before-save where possible, and fault paths are added. Each migration is tested against scenarios before the legacy automation is switched off in production.
Our Salesforce admin is leaving. What do we do before deactivating the user?
Before deactivation, find everything that runs under the user: scheduled jobs, OAuth connections, Email-to-Case, outbound messages, dashboards and alert recipients. Move each item to a new owner following a written change plan and runbook, and confirm that access is really closed, for example when the user has a local password or permission to bypass MFA. Deactivating first often stops processes without a visible error.
How do you audit permissions and field-level security in Salesforce?
We review profiles, permission sets, sharing rules and the role hierarchy to establish who sees which records and fields. We look in particular for integration users on a System Administrator profile, users who can bypass MFA, and sensitive fields without proper FLS. Then we move access to permission sets and permission set groups and test every role against a real scenario.
How do you measure ARR in Salesforce when the data is messy?
Start by finding where revenue really lives: contract lines, subscriptions or Opportunity Products. Then build a scheduled job that writes a snapshot per account per period and classifies every change as new, expansion, contraction or churn, with a renewal control that flags dates that do not match the last revenue month. CloudX specializes in building ARR measurement tools inside Salesforce.
Can we improve Salesforce without disrupting daily work?
Yes. Every change is built and tested in a sandbox, moved through source control and the Salesforce CLI, and deployed with a rollback plan. Sensitive changes are scheduled in advance with a runbook, and the team keeps working as usual while improvements go live in phases.
Do you work on orgs implemented by another partner?
Yes, most of our optimization work is on orgs implemented by others or built up over the years by several people. We start by reading and documenting the existing configuration, so even without proper documentation you leave the health check with a clear picture of what runs and why.
Last updated: