Sahil Goura Salesforce Developer

I'm happy to help. Can you tell me more about what you'd like to discuss, Sahil Gorra? I'm 2 times Salesforce certified, that is, I hold Salesforce admin associate certification.

What governance standards? So governance standards, which we enforce on Salesforce, is that we ensure that data mapping is getting done correctly. And even more, we can do governance standards. Governance standards would be particularly defining the rules, accessing controls, encrypting data, monitoring user activities, and checking the data is mapped correctly using validation rules. Another key element would be data quality, which ensures that data is accurate, complete, consistent, and timely. Once it's mapped, if there's data skew or data inconsistency, we follow standard processes to restore from the backup, and then start the process again, such as any flow or automation process, and then do it again after restoring from the backup.

When I troubleshoot a Salesforce integration issue where account data is not syncing correctly with an ERP system, I first go to the Salesforce object manager, then to cases, field and relationships, and check if any additional case fields were created in our Salesforce case object. Next, I open the case object and examine the data that has been created, checking for any redundant data or missing data. Then, I use Workbench, particularly for the ERP system, to ensure that the integration is set up correctly. I use the super rest API, mainly the rest API, to get a query and understand what data is there. I then remove the data and perform a post query to remove any inconsistencies and ensure that the data is properly integrated after it is moved from Salesforce to the third-party application.

We can't use sharing rules, and we can't restrict access below our organization by default setting. That is public read only private, public read only, and public read. This is a necessary setting that is the most narrow and is at the bottom. Right? It is a necessary setting that is the most narrow and is at the bottom. Then, to troubleshoot complex sharing rules, I'll first check the sharing settings. I'll go to the sharing settings to check what they are. I'll first check the profiles, then the permissions and its rules to see if everything is mapped or not. Next, I'll go to the sharing settings to check what all accesses are given to a team. I'll also check for all sharing inconsistencies. Then, I can remove all the sharing settings or sharing tools and create new ones. Alternatively, I can troubleshoot the proper setting by removing it all and re-creating the sharing rules. It's better to create a new sharing rule set or new sharing rules so that they won't affect another set of people. This way, we can resolve the issue.

Okay, how do you manage and assign correct permissions for a new hire in the sales department in Salesforce? So if we've talked about it. So then the approach we follow is we go to the user. We go to Setup, then we go to the quick find box, enter Users. We will select the user. Then after selecting the user, in the permission set setup, we'll click on edit assignment. After editing, we'll click on that to assign a permission set. This is something to add a permission. But if you're talking about now for a new hire, so let's say the person is hired for a sales department. We'll check and determine his level. Either he's a sales executive, he's a sales representative, he's a sales manager. Depending on his profile, then his role hierarchy. Then on what level he is, we'll first give him a profile and then a role. And after that, he'll be present in the role hierarchy. Depending on that, he will have all the required permissions, such as create, read, update, and delete. So mostly delete permission is not given. Usually create and read permissions are given, and sometimes update permission is also not given depending on the requirements. And after that, once we have provided them the role and profile, we'll also create a permission set if it requires something else. And after creating a permission set, we'll make sure he has all the accesses, so he can access anything. Because many times, if someone sends us a link and the user doesn't have access to that data in Salesforce, the link will be broken and won't show. But in this scenario, if we've given him the permissions, then he'll be able to see that object or that data, even a report or a dashboard required by him but not having that permission. So by giving him that permission set, this is the way I'll manage and assign the correct permissions for a new hire.

New Salesforce release. Okay. So I'll say when a new Salesforce release is announced, what steps do you follow to evaluate and implement new features? So first, I'll check the release, whatever we have in the release. And I'll first, familiarize myself with all the release notes. And even as I use a sandbox to check my org's compatibility with Salesforce major releases before it is released in a live production environment. Now Salesforce has major three releases in a year to improve the quality of life updates, new features, and security enhancements. And now we test these features rigorously. Okay? And now the specific requirements we need to consider before the major release is something, let's say, we need to plan ahead. And before any release, Salesforce publishes all the release dates on Salesforce Trust. After that, we review all the release notes, listing all the new changes, critical updates. And we also learn how to use the release notes and identify which production features our company uses. So let's say our company, 2K Technologies, uses Salesforce Einstein. And for inbox and outbound integration with Outlook. So whatever emails or events we create on Outlook, it gets reflected into Salesforce. And whatever event we create in Salesforce, it gets reflected into Outlook. So this is the thing. So depending on the features we use, I'll check on those features. Then we'll use release metrics to identify what new features and changes can impact our port and if any action is required. Now I'll check the release readiness trail with the community, which is posted before a month. After that, we'll test and test. Major releases are first present in sandboxes approximately around four to six weeks before it's live. So we have time to review our new features, and we can take them for a test drive. And understanding the sandbox preview process, how it's working, is it working fine or not, we can either ensure that it is aligning with that testing. Or if it is working fine, otherwise, we can rule out the changes. And we should not do those changes if there's an issue. We should not do those changes in the production environment. Otherwise, if everything's working fine, we can directly, after proper rigorous regression testing, send it to our Salesforce production environment. If whatever features are required and if something is mandatory and it's better. So let's say Salesforce introduced this validation rules. Instead of creating a validation rule or creating a trigger, we can now create a validation rule within flows itself. So that's a new thing, and that's a betterment. So this is something which, after rigorous testing on sandbox, we can use and implement in our Salesforce work.

No. Setup. If you need to set up a workflow for a lead follow-up task, what Salesforce tool would you use? Okay, so here, since we know that workflow and process builders have become obsolete, now major companies who are using these things have an option to convert it into a flow. So we can directly convert it into a flow, but the better approach we can follow is we can create that flow from scratch so that whatever integration or whatever issues we had beforehand, it should not be a problem, and they will not be, again, redundant and make the case redundant. And the flow should properly work. So the major tool which we primarily use will be Flow. And for a lead follow-up task, Flow will be using Flow Builders, we can create automated workflows, processes even using a visual interface. Salesforce flow also enables the creation of simple and complex automation. And, lead follow-up task. So, basically, lead follow-up task will create a proper flow from a start element, then we'll add a decision element. After adding that decision element, we'll see if it's a yes or a no. Then after that, we'll set up a proper lead process and we can also use a lead assignment rule and an approval process also could be used. And after that, we can achieve this.

The major difference between profiles and roles is that a profile is something which is mandatory for a user. A user can't be created without a profile, and rules are something which are not mandatory, but it gives us data visibility. A profile gives us access to the objects like account, contacts, opportunities, and all of this stuff. Whereas, roles give us data visibility. We have two types of security settings. One is object level security, and the second is record level security. In object level security, we have profiles and roles and even permission sets. Profiles give us object level security, which gives us visibility. The major example here is if we have 50 records and we want the user to only show 40 records. So, we can use this role, and from this role, that user could only see those 40 even though that org is having 50 records. That is a major difference between profile and role. And now, talking about the permissions, it's whatever permissions that role does not have. So rather than giving those permissions to that particular specific profile, what we can do is we can give additional permissions to a permission set to let's say, that particular sales user who requires that permission. And this way, rather than giving them to all the users, we can give that permission set to that user. Once his work is done, we can remove that permission. Now we have record level security. In record level security, we have the OWP setting that is organization by default, which is private, public read-only, and public read. Then we have the whole hierarchy, which is let's say we have a sales executive, and there's above sales manager and above him all. So all the records which a sales executive can see or even private records which for which the sales executive is the owner, they can be not only read but also edited by the above or hierarchy. Let's say sales manager, CEO, all the above them. And majorly, we can't disable this rule hierarchy for standard objects. We can only disable it for custom objects, but this is something rule hierarchy. And then we have sharing rules, which is criteria-based and owner-based sharing. And then we have manual sharing. If you want to share a few 1 or 2 or few reports, then we can use manual sharing. Then we have Apex-based sharing also. So, majorly, I have already explained the difference between profiles and roles. Thanks.

A plan for restructuring of Salesforce roles and profiles that requires minimizing disruption to existing workflows and data accessibility. So, if you want to restructure Salesforce, I'm using minimum disruption. So, what we'll do is check the whole role hierarchy, and we'll check for all the people, profiles, and rules. And first of all, we'll deactivate all those users which are not required, and we'll make sure that they are deactivated and have a license free. And before that, we'll check all the workflows, process builders, or all the things from which they're connected. We'll tell users to send it to a delegated user. And then after that, we have Salesforce roles and profiles. So, in that existing work, we'll check what's the best way is to check and go and check and even map out which workflow and which flow our process builders, which profile is integrated to, then create a map. And first of all, we'll go for those profiles which are heavily integrated with workflows and automation and which can be disrupted. So, first of all, we'll make a list of all those and we'll keep them aside. We'll not change anything. Then whatever is having the least connection to the workflow or even we can send it to a delegated user or even those profiles which can have their logics delegated or even removed. We'll go through this manner. So, first of all, those profiles which have intense, important, and having the maximum workflows and automation rules, we won't disrupt them. Second will be where we can change or delegate it to some user. And third, the profile will be that in which it's either not connected or even connected to just one or two workflows. This will be a better plan for restructuring.

How do you use Salesforce? So Salesforce provides great reporting and analytics to inform business decisions. It provides a great report and dashboard to provide proper metrics of data in different time periods and data types, using funnels, bars, histograms, and all. It provides a great reporting structure with all the filters and everything. To use Salesforce for reporting and analytics, I'll first get all the data points from the desired duration, numbers, and so on. Let's say from 1 million to 10 million records from 2011 to 2024. I'll then check the data points for the year, required numbers, companies, people, position, profile rules, and so on. After collecting all the data points, I'll create a report based on different rules and data points, such as different years, year-on-year growth, and different sales cloud categories. Depending on the report requirements, I'll provide different sets of reports. I'll also create a dynamic dashboard so every user can access this information. I'll do some bucketing to group related data points together, making it easier for users to access. I'll use Salesforce for reporting and analytics, as well as dashboarding, to provide a proper picture. I'll remove any filters or fields that are not required, and add any additional data points or calculations that are needed. If stakeholders want to remove a certain year or add a new one, I'll make the necessary adjustments. Depending on the stakeholders' requirements, we may need to make multiple iterations. One of the better platforms for reporting and analytics is Tableau, and also Power BI. In terms of reporting and analytics, they're much better than Salesforce, particularly here. Many companies have started using Tableau and Power BI to make reporting and dashboarding easier, more dynamic, and with a much better scope, allowing for better reporting and dashboarding.

When dealing with large-scale data migration, what steps do you take to mitigate the risk related to Salesforce's government limits? So, there are certain best practices where, for example, we have best practices for triggers or coding. We also have best practices for data migration, especially when dealing with large scales at the millions of data records we are talking about. So, here are some best practices which we need to follow. First of all, we need to identify the data we need to migrate, which is choosing the objects we need to migrate. Let's say, deciding whether migrating only the contact information from each account or migrating the account information also. Secondly, we will be creating templates for the data. These templates will be like creating an Excel template for each object using a data export from data loader and using insert, update, delete, and upsert data using data loader. Now, since objects have mandatory relationships which dictate the order of data migration, we need to identify the required fields for each object, and this will help us reviewing the data before populating the template. For example, we'll load one record and then check the results, and then we can load all the records. After that, we'll prepare the destination, and we'll consider using custom fields to store any legacy ID information and creating custom pages to store the data contained in nonstandard fields in our organization. We can give an example, like using home phone for users. Next, we'll validate the data using this technique, like creating custom reports to validate the account records and provide an overall snapshot of migration. Then, we can build a report, and we can spot-check the data and review the exception records. We'll create exception reports to see which data was not migrated. After checking which data was not migrated, we can either re-migrate it or restore the backup. If there is any data skew or inconsistency, we can restore the backup, and we'll make sure that whatever data was not mapped properly or what issue was last time, we will remove and rectify that error. After rectifying that error, we'll make sure that all the data records are there. We'll also check the log file to see if the data that failed last time will fail again. If so, we'll send those data for re-migration and check why it failed, and then we can again migrate it.