Implementing Salesforce or already using Salesforce? Do you have a well-defined development & release management process to ensure that you are doing it the right way, using all the proper tools & technologies, automating processes where it can and should be automated?
Do you have a proper process to ensure that you are building an optimal solution on Salesforce, leveraging on the platform’s features and capabilities, not incurring technical debt and not cutting corners on best practices?
If your Flow includes a DML element such as Create, Update or Delete records, or a Submit for Approval core action, then there is a possibility that it might fail. For example, a create or update may fail if it does not pass the validation rule. And when the flow fails, Salesforce displays a standard message in red text that reads “An unhandled fault has occurred in this flow”. But with an error message like this, users will have no clue of what happened and if they did anything wrong.
A better option is to use something called ‘Fault’ path in Flow. Fault Path is also called Fault Connector or Fault Line. With Fault path, you can display a more meaningful message and guide users on what to do. To create a fault path, create a screen element with useful message and connect it to the DML element.
How do you delete or deactivate the apex classes / triggers on your Salesforce Production Org? Unfortunately, it is not as simple as going to the Apex class and hitting the delete button or unchecking the ‘Active’ checkbox.
For deleting or disabling the code, you can take one of the following two routes:
You can create something called ‘Bucket’ field in Salesforce. With Bucket fields you can categorize the records in the report itself and on the fly. You don’t need to create a custom field on the object for this.
For example, let say that if you are creating a report on Opportunity and want to categorize the opportunities in the buckets of ‘small’, ‘medium’ & ‘large’ based on the opportunity amount. You don’t need to define this category as a formula field on the Opportunity object. You can create a bucket field in the report and categorize opportunity records on the fly in report itself.
Custom Permissions in Salesforce are used to give access to users for certain apps or processes that you have configured and which cannot be controlled by profile or permission set directly.
A profile and a permission set control the users’ access to many entities such as objects, fields, tabs, and Visualforce pages. However, they cannot control a custom process that you have which is unique to your business. For e.g. only specific users should be able to edit an Opportunity once it is Closed Won or save records bypassing validation rules. To manage these granularities, you can leverage Custom Permissions in Salesforce. They let you define checkpoints that can be assigned to users via permission sets or profiles, in the same way how other permissions are assigned to users.