How To Choose A Salesforce Partner In 2026
Every Salesforce partner in 2026 has a deck. Slides about transformation. Words like agentic and data-native and AI-first. All of them sound prepared. Very few of them are asking about your business before they start selling you their methodology. Choosing wrong costs more than the invoice. It costs the months of internal time spent managing a partner that was never the right fit, the rework that follows a go-live nobody was proud of, and the political capital burned explaining to leadership why the CRM still does not do what it was supposed to do. The market in 2026 is noisier than it has ever been There are over two thousand registered Salesforce consulting partners globally. A significant portion of them have restructured their positioning in the last eighteen months to lead with AI. Some of them have earned that positioning. Others have added the word Agentforce to their website and called it a capability. The noise is not the problem. The problem is that buyers have less time to filter it than ever, and the signals that used to indicate quality, certification counts, tier badges, years in the ecosystem, are no longer sufficient differentiators on their own. A Summit-tier partner with eight hundred certified professionals can still assign your project to a team that has never solved a problem like yours. The right question is not which partner is most impressive. It is which partner is most likely to deliver the specific outcome your organisation needs, at the pace you need it, without creating a dependency you cannot get out of. Start with business alignment, not technical credentials The first conversation with a prospective partner should not be about their methodology. It should be about your business. What are the actual outcomes you need Salesforce to produce. Not features, not clouds, not integrations. Outcomes. A partner worth working with will ask what success looks like in twelve months and push back if the answer is vague. They will want to understand your sales motion, your service model, your data landscape, and your internal capacity before they suggest a solution architecture. If a partner has already drafted a proposal before understanding any of that, the proposal is not for your business. It is for the last business that looked roughly similar. Business alignment means the partner understands the commercial problem you are trying to solve and can connect every element of the implementation to that problem. It means they will tell you when a feature you asked for does not actually solve the problem, rather than building it because it was in scope. That kind of honesty is less common than it should be and considerably more valuable than a polished slide on transformation. Time-to-value is a strategy question, not a project management question Most Salesforce implementations take longer than planned. Some of that is scope change. Some of it is data quality problems nobody anticipated. Some of it is a partner that builds for elegance when the business needed something working by the end of the quarter. Time-to-value as a selection criterion means asking prospective partners how they sequence delivery. Do they phase the work so users get something useful early, or do they build the complete solution and hand it over at the end of a long engagement. The second model is fine for certain types of projects. For most CRM implementations, where adoption depends on users seeing value before they form opinions about whether the system works, phased delivery with early wins is materially better. Ask specifically for examples where a partner delivered measurable business value within the first sixty to ninety days of a project. What did that look like. What was the business outcome. If they struggle to answer with specifics, the concept of time-to-value may be on their website but not in their delivery approach. What AI and data depth actually means in a partner context Every partner claims AI capability in 2026. The useful distinction is between partners who can configure Agentforce features and partners who can design an AI strategy that is grounded in how your data is structured, how your processes work, and what your users will actually adopt. The first group can get Einstein features switched on. The second group can tell you why those features will produce poor outputs if the underlying data has not been unified, why a particular agent use case will not work in your service model without process redesign, and what the governance model for AI-generated content needs to look like in your industry. A straightforward way to test this is to ask a prospective partner about a situation where they recommended against an AI feature a client wanted to deploy. If the answer involves a conversation about data quality, user trust, or process readiness rather than just technical constraints, that is a partner operating at the right level of depth. If they have never had that conversation, they are likely saying yes to everything and hoping the outcomes follow. On Data Cloud and Zero Copy specifically, the partner should be able to explain the trade-offs between ingestion and federation without prompting. They should have a position on identity resolution at scale and know where it works well versus where it produces frustrating results. Platform enthusiasm is not the same as platform knowledge. Risk reduction as a selection criterion Risk in a Salesforce implementation comes from several predictable directions. Scope that was never clearly defined. A project team that is strong in presales and thin in delivery. Technical debt from a previous implementation that nobody fully disclosed. Data migration that was underestimated. Change management that was treated as a training exercise rather than an organisational commitment. When evaluating a partner, ask directly how they handle each of these. Not in general terms. With specific examples from projects they have delivered. A partner that has never dealt with a troubled legacy org, a difficult data migration, or a client whose internal teams were not aligned going
How Upload Custom Metadata Type from CSV
Salesforce said no to Data Loader for custom metadata. Here is what actually works. The first time most admins try to load custom metadata type records in bulk, they open Data Loader out of habit. Data Loader does not support custom metadata types. It never has. That is not an oversight. Custom metadata lives in the metadata layer, not the data layer, which means the tools built for data records simply do not apply. The good news is that there are three approaches that do work, and choosing the right one depends on who is doing the loading and how many records are involved. Why custom metadata types are different Custom metadata types store configuration, not transactional data. Validation rules, routing logic, feature flags, mapping tables, rate cards, and similar reference data all live there. Because they are part of the metadata layer, they are deployable between environments, version-controllable, and accessible in formula fields and flows without additional SOQL queries. That architecture is what makes them useful. It is also what makes bulk loading feel counterintuitive at first. You are not inserting records into a database table. You are deploying metadata through the Metadata API. Once that distinction is clear, the available approaches make considerably more sense. There are three reliable ways to load custom metadata type records from a CSV file. The Custom Metadata Loader app, the Salesforce CLI, and a Flow-based component. Each has a different profile in terms of setup effort, permissions required, and practical limits. Option one: the Custom Metadata Loader app The Custom Metadata Loader is a Salesforce-built tool available on GitHub. It was the standard approach before CLI commands became generally available, and it remains the most admin-friendly option for teams not using a developer toolchain. Setup requires a one-time deployment to the org, after which admins with the correct permission set can load records directly from the UI without touching a terminal. The tool uses the Metadata API in the background and can process up to 200 records per call. The setup process follows these steps: Download the Custom Metadata Loader from the Salesforce GitHub repository and create a zip file from the contents of the custom_md_loader directory. The package.xml file should sit at the top level of the zip, not inside a subfolder. Log in to Workbench with the target org credentials, navigate to Migration and then Deploy, and upload the zip file. Once deployed, go to Setup and assign the Custom Metadata Loader permission set to anyone who will use the tool. Open the Custom Metadata Loader app from the App Picker and configure Remote Site Settings if prompted. To load records, prepare a CSV file where the header row contains the API names of the custom metadata type fields. The Label or DeveloperName field is required in every file. Either one is sufficient to identify new records or update existing ones. If the org has a namespace, include the namespace prefix in the field API names in the CSV header. Duplicate Label or DeveloperName entries in the file will result in only the last row being processed. Upload the CSV file, select the corresponding custom metadata type from the dropdown, and click Create/Update. The tool will confirm how many records were processed and flag any errors in the output. The 200-record limit per call is worth noting. For larger datasets, the file needs to be split. For very large migrations, the CLI approach removes this constraint entirely. Option two: Salesforce CLI As of Summer 2020, the Salesforce CLI includes dedicated commands for custom metadata types. This is the approach Salesforce now recommends for development workflows, and it has no record limit. The relevant command for inserting records from a CSV file is: sf cmdt generate records –csv CountryMapping.csv –type-name CountryMapping__mdt This command generates the custom metadata record files locally in the project directory. The records then need to be deployed to the org using the standard deploy command: sf project deploy start This command generates the custom metadata record files locally in the project directory. The records then need to be deployed to the org using the standard deploy command: The CSV file format follows the same rules as the Loader approach. The header row must contain field API names, and either Label or DeveloperName is required. The DeveloperName value can only contain alphanumeric characters and underscores, must begin with a letter, and cannot end with an underscore or contain two consecutive underscores. Spaces in name values should be replaced with underscores. The CLI approach fits naturally into a DevOps pipeline. Records can be committed to version control, reviewed before deployment, and promoted through environments using the same workflow as any other metadata change. For teams already running a source-driven development model, this is the more sustainable long-term approach. The steps for a first-time setup follow this sequence: Install the Salesforce CLI and authenticate with the target org using sf org login. Create or open an existing SFDX project in VS Code. Retrieve the custom metadata type definition from the org so the project is aware of its field structure. Prepare the CSV file with the correct field API names in the header row. Run the cmdt generate records command, review the generated files in the CustomMetadata folder, and deploy to org. Option three: a Flow-based screen component For orgs where neither GitHub deployment nor CLI access is practical, a third option exists in the form of a community-built Flow screen component. This approach allows admins to upload a CSV directly from a screen flow in the org, with no external tooling required. The component was created by Salesforce MVP Narender Singh and is available through the UnofficialSF community. It handles the Metadata API calls internally, so the user experience is simply uploading a file and selecting the metadata type. This approach is most appropriate for one-off loads in environments with restricted developer access or where deploying external tools to the org is not straightforward. It is less
How to write Unit Tests with Service Locator
Step-by-step example how to write Salesforce Apex unit tests using the Service Locator pattern.
Salesforce Unit Test Best Practices
TrueSolv guide to Salesforce Apex unit test to validate logic and keep deployments reliable without SeeAllData.
How to increase code coverage quickly in Salesforce
TrueSolv explains Salesforce Apex code coverage for deployments and AppExchange packages for safer releases.
How to develop flexible Apex code for Salesforce
Day-to-day developer work related not only with writing new functionality but updating existing ones. When a developer tasked with adding a new feature to an existing application, the goal is to extend the functionality of that application with new behaviors. Extending software is the introduction of a new behavior by the addition of code. Some applications are flexible to this kind of change, whereas others may fight you tooth and nail! Flexibility is how easily software can adapt to shifting requirements. In an ideal extensible system, adding new behavior involves strictly adding new code without changing existing code. Adding new behavior to an extensible system means adding new classes, methods, functions, or data that encapsulate the new behavior. But because real systems are rarely ideal, you’ll still find yourself needing to make changes to existing code regularly. One of the things that help developers write clean, well-structured, and easily-maintainable code is SOLID principles.
How To Send Custom Desktop/Push Notifications In Salesforce
Everyone knows that it is so important to send notifications when important events occur. For example, alert an account owner if a new support case is logged while trying to close a deal. Or, send a notification for a unique workflow built entirely with custom objects. Previously, you could send only standard notifications for use cases predefined by Salesforce. Custom notifications allow you to send important information to your users via push to mobile or desktop alerts. Now you can fully customize the notifications to inform users of record information, changes, and updates. Custom notifications will bring relevant information to your users at the right time!
How To Invoke Apex From Lightning Page Layout Without Modal
In some cases, you need to place a button to Standard Salesforce Layout to invoke the Apex method without any confirmation or close buttons. If you work in Visualforce OnClick JavaScript is the best solution.
How to fix the caching problem in Salesforce Lighting Component
Salesforce trying to optimize performance by caching components on the client-side. This is awesome for the end-users because page loads will faster. This is a lot less awesome for developers when developing lightning components because they may think that the code is wrong. Often they have to hit hard refresh a few times while you wait for the cache to clear.
How to Increase Salesforce Governor Limits
Salesforce is known as CRM with a lot of Limits. Because Salesforce Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits so that runaway Apex code or processes don’t monopolize shared resources. If some Apex code exceeds a limit, the associated governor issues a runtime exception that cannot be handled.