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.
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.
How to Build Custom Flexible Rest Architecture in the Salesforce
The Classic Salesforce platform is designed to use the MVC pattern for developing applications and customizing existing functionality. The benefits of server rendering are obvious, but we often need more dynamic in the application. In this case, Rest Services will help us. By default, Salesforce has the following capabilities: Rest API Soap API Remote Actions The platform is also known for its limits. In this case — API Usage Limit. We will get rid of the problems and overcome the limits. Solution The solution is to use the standard Visualforce page with a custom controller to get the result of the request. As a result, we have a page with the following contents: 📄 Copy to clipboard 1 2 3 4 5 6 <apex:page controller="GS_RestApiController" action="{!execute}" contenttype="text/javascript" showHeader="false" sidebar="false"> <apex:outputText value="{!response}" escape="false"/> </apex:page> The method execute from the GS_RestApiController controller will be executed when the page is loaded. The result will be bound into the outputText. Controller Code: 📄 Copy to clipboard 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 public class GS_RestApiController { private static final String COMMAND_NAME_PARAM = 'command'; private Map<String, String> commandAliasNameMap = new Map<String, String>{ 'test' => 'FirstTest' }; public String response {get; private set;} public GS_RestApiController() { } public void execute() { this.response = getCommand().execute().toJSON(); } private GS_CommandContainer.GS_Command getCommand() { Map<String, String> params = ApexPages.currentPage().getParameters(); String commandName = params.get(COMMAND_NAME_PARAM); if (commandAliasNameMap.containsKey(commandName)) { commandName = commandAliasNameMap.get(commandName); } params.remove(COMMAND_NAME_PARAM); return GS_CommandFactory.create(commandName, params); } } In the controller, we use the command param to execute the command, and we have the map between the command and its alias if necessary. All commands are stored in container class — GS_CommandContainer 📄 Copy to clipboard 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 public class GS_CommandContainer { public abstract class GS_Command { private Map<String, String> params = new Map<String, String>(); public void setParams(Map<String, String> params) { this.params = params; } public GS_RestResponse execute() { try { Object resultObject = perform(); return new GS_RestResponse(GS_StatusCode.OK, getMessage(), resultObject); } catch (GS_Exception exp) { String message = exp.getMessage() + exp.getStackTraceString(); return new GS_RestResponse(GS_StatusCode.ERROR, message); } catch (Exception exp) { String message = exp.getMessage() + exp.getStackTraceString(); return new GS_RestResponse(GS_StatusCode.ERROR, message); } } public abstract Object perform(); public virtual String getMessage() { return null; } } public class GS_DefaultCommand extends GS_Command { public override Object perform() { return 'This is defult result.'; } public override String getMessage() { return 'This is default message.'; } } Thus, to add a new command, it is necessary simply to extend the base class GS_Command and implement the perform() method where the execution logic will be present. GS_CommandFactory is designed to create an instance of the GS_Command class. 📄 Copy to clipboard 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 public class GS_CommandFactory { private static final String DOT = '.'; private static final String COMMAND_CONTAINER_NAME = 'GS_CommandContainer'; private static final String DEFAULT_COMMAND_NAME = 'GS_DefaultCommand'; private static final String COMMAND_NAME_TEMPLATE = 'GS_{0}Command'; private static final String COMMAND_NAME_TEMPLATE_WITH_CONTAINER = COMMAND_CONTAINER_NAME + DOT + COMMAND_NAME_TEMPLATE; private static final String DEFAULT_COMMAND_NAME_TEMPLATE_WITH_CONTAINER = COMMAND_CONTAINER_NAME + DOT + DEFAULT_COMMAND_NAME; public static GS_CommandContainer.GS_Command create() { Type commandType = Type.forName(DEFAULT_COMMAND_NAME_TEMPLATE_WITH_CONTAINER); GS_CommandContainer.GS_Command command = (GS_CommandContainer.GS_Command)commandType.newInstance(); return command; } public static GS_CommandContainer.GS_Command create(String commandName, Map<String, String> params) { if(String.isBlank(commandName)) { create(); } String commandClassName = String.format(COMMAND_NAME_TEMPLATE_WITH_CONTAINER, new String[] {commandName}); Type commandType = Type.forName(commandClassName); if(commandType == null) { commandType = Type.forName(DEFAULT_COMMAND_NAME_TEMPLATE_WITH_CONTAINER); } GS_CommandContainer.GS_Command command = (GS_CommandContainer.GS_Command)commandType.newInstance(); command.setParams(params); return command; } } It creates an instance of the required command, depending on the given parameter, or creates an instance of the default class if no such command is found. The example of use is quite simple: 📄 Copy to clipboard 1 var result = $.post('{!Page.RestApi}', {command : 'test'}); The result is: 📄 Copy to clipboard 1 {"result":"FirstTestResult + Params : {}","message":"FirstTestMessage","code":200} When you perform a request without any parameters, the default command is executed. The command name must match the COMMAND_NAME_TEMPLATE template described in GS_CommandFactory, and it is also possible to add the alias and command name to the commandAliasNameMap in the GS_RestApiController. From our side, the architecture is convenient and easily extensible. The source code you can find on GitHub. Nowadays, when Lightning Components is became standard for developing UI. It make less sense. But it can help you if you make custom UI with any JS framework (Angular, React, Vue) or you faced with any problem related with AuraEnabled methods.
How to fix ‘Error: Incorrect parameter type for function ‘ISPICKVAL()’’
You can face a strange issue if you create a formula field in Salesforce and try to use standard ISPICKVAL function with Custom Label because you don’t want to hardcode the values.
