In the Salesforce, you are required to ensure that users can only log in from a specific set of IP addresses. How would you achieve this at the organization level?
To restrict users from logging in only from a specific set of IP addresses, you would use the “Login IP Ranges” feature at the profile or permission set level in Salesforce.
Explanation: In Salesforce, “Login IP Ranges” allows administrators to specify a range of allowed IP addresses from which users can log in. If a user tries to log in from an IP address outside of this range, will be denied access.
To set this: they
- Navigate to the profile (or permission set) you want to configure.
- Under the “Login IP Ranges” section, you can specify the start and end of the allowed IP range.
- Save the settings.
It’s crucial to note that while “Login IP Ranges” restricts where a user can log in from, it doesn’t restrict when they can log in. For that, you’d use “Login Hours”.
Your organization wants to enforce a policy where users are required to change their passwords every 30 days and the password must be at least 10 characters long. How would you implement this in Salesforce at the organization level?
In Salesforce, under “Password Policies”, you have the ability to define the lifespan of a user’s password and the complexity of the password.
Here’s how you’d set it up:
From the Salesforce setup area, navigate to Security Controls > Password Policies.
Set ‘Password Expires In’ to 30 days.
Set ‘Minimum Password Length’ to 10 characters.
Save the settings.
With these settings in place, users would be prompted to change their password every 30 days, and the system would enforce the requirement of a password being at least 10 characters long.
In Salesforce, how would you restrict users from accessing the Salesforce application outside of regular business hours, say from 9 AM to 5 PM?
In Salesforce, the “Login Hours” feature allows you to specify the time frames during which users can log into the system based on their assigned profile.
Here’s how you’d set it:
1. Navigate to Setup
2. Search for and select the desired profile.
3. In the profile’s settings, scroll to “Login Hours.”
4. Here, you can set the permitted login start and end times for each day of the week.
5. For your scenario, you’d set the start time to 9 AM and the end time to 5 PM for weekdays.
You have sensitive data in certain Salesforce objects, and you want to monitor and be notified if there are unexpected or large data exports. How would you set up this monitoring at the organization level in Salesforce?
To monitor and be notified of unexpected or large data exports in Salesforce, you would use the “Event Monitoring” tool, particularly the “Report Export” event type.
Salesforce’s Event Monitoring provides a suite of event logs that give visibility into your organization’s operational use patterns and behaviors. One of these event types is “Report Export,” which logs when a user exports (downloads) a report to a CSV file.
Here’s how to set it up:
1. Go to Setup in Salesforce.
2. In the Quick Find box, type “Event Monitoring.”
3. Select the “Event Manager.”
4. From here, you can view different event logs, including the “Report Export” log.
5. You can set up alerts to notify you when certain thresholds are exceeded, such as when a user exports a large volume of data.
By monitoring the “Report Export” event, you’ll get insights into who is exporting data, what data they’re exporting, and when they’re doing it. This can be crucial in ensuring sensitive data isn’t being accessed or exported inappropriately.
In your Salesforce organization, you’ve observed that certain sensitive fields are being accessed by more users than expected. How would you set up a mechanism to track which users are viewing these sensitive fields?
The feature you’d use in Salesforce to track access to specific fields is called “Field Audit Trail”.
With Salesforce’s Field Audit Trail, you can get a detailed history of who has viewed or changed specific fields in records. It provides an added layer of visibility, especially for sensitive data.
Here’s how to set it up:
1. Navigate to Setup.
2. Search for the object that contains the sensitive field you want to monitor
3. Under the object, go to “Fields & Relationships.”
4. Find the specific field you want to track and click on it.
5. Click on “Set History Tracking.”
6. Check the box next to “Enable” for that field.
Once this is done, every time the field is viewed or edited, Salesforce will create a history record indicating which user accessed the field and when.
Limitation of Field History Tracking
The data collected by field history Tracking is both too much, and not enough. You’ll get a lot of information, but only up to a certain point — a maximum of 20 fields can be selected per Object, and only 18 months of data (24 using the API) are collected.
Additionally, Field History Tracking only records changes from the time it’s enabled onward — which can be a problem if you aren’t taking time to determine what’s in scope ahead of time. 
You’ve been tasked to keep track of changes made to the metadata and setup configurations in your Salesforce organization. How would you monitor these changes, especially for critical configurations, using Salesforce’s built-in features?
The Setup Audit Trail in Salesforce provides a mechanism to track changes made in the setup area of your Salesforce organization. It helps you understand who did what and when, which is vital for maintaining security and for understanding the cause of any unintended setup changes.
Here’s how you can view the Setup Audit Trail:
1. Navigate to Setup
2. In the Quick Find box, type “Setup Audit Trail.”
3. Click on the “View Setup Audit Trail” link.
Here you’ll find the last 20 changes made in your setup. You’ll see information like who made the change, what the change was, and when it was made.
Additionally, Salesforce also offers the ability to download the last six months of setup audit trail changes as a CSV file.
Using the Setup Audit Trail, you can monitor crucial configuration changes, such as changes to security settings, field customizations, and user permissions.
Limitation of Audit Trail
it only stores that data for 180 days. This means that any changes your auditors want to see beyond that timeframe would be unobtainable.
The other major problem with the Setup Audit Trail is that, while it shows you the changes that took place in your Org, it doesn’t show if they were reviewed or approved — critical details for auditors who will want to see that sensitive changes followed an appropriate process.
Transaction Security Policies
You want to get an alert or block an action if a user tries to download more than a specific number of records from a report. How will you achieve that?
You will use Transaction Security Policies:
Actively monitors and can intervene in real-time if specific transaction criteria are met.
You can set rules or policies that trigger when certain conditions are met during transactions.
Once triggered, these policies can notify the administrator, block the transaction, or both.
It’s a proactive way to prevent unwanted behavior in real-time.
Setup
Session Settings
Your company has just undergone an IT audit, and for compliance reasons, they’ve requested that all users in your Salesforce organization have their passwords expired, forcing everyone to set a new password on their next login. How would you achieve this in Salesforce?
To expire all passwords and force every user to reset their password upon the next login, you can use the “Expire All Passwords” feature in Salesforce.
1. Navigate to Setup.
2. In the Quick Find box, type “Expire All Passwords”.
3. There’s an option to “Expire All Passwords”. Clicking on this button will expire passwords for all users.
4. Users will be prompted to set a new password the next time they attempt to log in.
Your company wants to increase its security posture regarding user sessions in Salesforce. They’ve provided the following requirements:
Users should be automatically logged out after 15 minutes of inactivity.
How would you configure these settings in Salesforce to meet the requirements?
To meet the provided requirements regarding user sessions in Salesforce, you’d make the following configurations in the Session Settings:
Set Session Timeout:
– Navigate to Setup.
– In the Quick Find box, type “Session Settings”.
– Click on “Session Settings” from the list.
– In the “Session Timeout Value” dropdown, select “15 minutes” to ensure users are logged out after 15 minutes of inactivity.
2. High-Risk Operations:
– Under the “Session Security Levels” section in Session Settings, there’s an option for “High Assurance”. Click “Edit” next to it.
– Check the box for “Require a verification code or security question answers when the following are true”.
– Set conditions as needed to define which operations are considered high-risk. This will require users to re-authenticate these operations.
How can you ensure users always access Salesforce through a secure/encrypted session?
In Session Settings, ensure the “Require secure connections (HTTPS)” option is checked. This forces users to access Salesforce using a secure and encrypted connection.
A user reports they are being logged out frequently despite being active. What could be a possible cause?
One possibility is that the “Session Timeout Value” is set to a very low value. Check the Session Settings to see the timeout value.
How would you ensure a user has to re-authenticate before performing specific high-risk actions, even if they are already logged into Salesforce?
In Session Settings, under the “Session Security Levels” section, you can define security levels such as “High Assurance”. You would then link this security level to the desired high-risk operations. When users try to perform these operations, they’d be prompted to re-authenticate.
My Domain
How does “My Domain” aid in preventing login CSRF (Cross-Site Request Forgery) attacks?
With “My Domain”, you can restrict login to only come through your custom domain. This means that generic Salesforce login pages or pages from potential malicious actors can’t be used to trick your users, effectively preventing login CSRF attacks.
Identity Connect
Your company has recently acquired another smaller company. The new employees are still using their original Active Directory (AD) credentials, while your primary team uses Salesforce. How would you ensure these new employees get seamless access to Salesforce?
By integrating Salesforce Identity Connect, we can connect the new company’s Active Directory to our Salesforce environment. This will facilitate Single Sign-On (SSO), allowing new employees to access Salesforce using their existing AD credentials seamlessly.
SAML
Your company has multiple applications, and users complain about having to remember multiple login credentials. You’ve been tasked with implementing a Single Sign-On (SSO) solution.
Real Time Example
Imagine you have a big building with many rooms (applications). Each room has a different key (login credential). People (users) are frustrated because they must carry and remember which key opens which door.
You want to provide a single keycard (Single Sign-On) that can open any room they’re allowed to enter.
How SAML helps:
1. Identity Provider (IdP): This is like a main reception or security desk in our building. Instead of going directly to the rooms, everyone first comes to this desk. This is where they show their ID once (log in once).
2. Service Providers (SPs): These are the individual rooms or applications. They trust the reception desk (IdP) to confirm if someone is who they claim to be.
Process:
1. A person (user) comes to any room (Service Provider or SP) in the building.
2. The room says, “Please check in at reception first” (redirects to the IdP).
3. At the reception (IdP), the person shows their ID (logs in).
4. The reception gives them a stampede pass (SAML assertion) that says, “Yes, this person is who they say they are.”
5. The person then goes back to the room, shows the stamped pass, and the door opens without asking for another key (because the room trusts the reception’s stamp).
In technical terms:
– The user tries to access an application (SP).
– The application redirects them to the IdP for authentication.
– Once authenticated at the IdP, they get a SAML assertion (a digital proof).
– The user takes this assertion back to the application (SP), which trusts the assertion from the IdP and grants access.
The beauty of this system is that after you’ve checked in at the reception once (logged into the IdP), you can visit any room you have access to without checking in again, thus making it a Single Sign-On (SSO) system.
SAML can be used to enable Single Sign-On (SSO) by setting up one of the applications as a SAML Identity Provider (IdP). Other applications are then configured as Service Providers (SPs). When a user tries to access any SP, they are redirected to the IdP for authentication. Post successful authentication, the IdP sends a SAML assertion to the SP, granting the user access.
Delegated Admin
Your company is expanding and has recently opened a new regional office in Europe. As an admin, you don’t want to be responsible for user management for this new office. How can you empower the European regional manager to manage users?
By setting up a Delegated Administrator You can specify that the regional manager can manage users with a specific role or within a particular role hierarchy, like all roles under “European Regional Sales.”
Your marketing team needs to frequently update picklist values for a custom field named “Campaign Type.” However, you want to ensure they don’t make modifications to other fields. How can you achieve this?
Create a delegated group for the marketing team and grant them permission to modify picklist values. Assign the “Campaign Type” field to this delegated group.
You have delegated user management to a team lead. However, the team lead reports that he cannot view certain profiles and roles while assigning them to new users. Why might this be, and how can you resolve it?
Delegated administrators can only assign users to profiles and roles that are specified in their delegated administration group. Ensure that the needed profiles and roles are included in the configuration of the delegated group for the team lead.
A delegated admin is reporting that they are unable to edit the login hours for users they are managing. What might be the reason?
Login hours are controlled by profiles. Even if a user is a delegated admin for managing certain users, they can’t change profile settings, including login hours, unless they have the necessary permissions on profiles.
Can a delegated admin modify sharing settings or create sharing rules for the objects they have access to?
No, delegated administration does not provide access to modify sharing settings or create sharing rules. It focuses on administrative tasks like user management and not on security or sharing architecture.
How to delete a Salesforce user?
Salesforce user cannot be deleted. They can only be deactivated.
What is the difference between freeze user and deactivate a user in Salesforce?
- Freezing user accounts does not make their user licenses available for the user in our org. To make their user license available, deactivate the account.
- Deactivating the user or freezing the user will not allow them to log in to salesforce org.
- In a scenario when we do not want a user to login into Salesforce org for some brief time like for a few months when they are on long leave then instead of deactivating the user we can freeze the user so that they cannot log in into the salesforce for that period.
What is view all and modify all in salesforce?
View all and Modify all permission ignore all the security setting and allow a user to view all the data and modify all the data in the salesforce org irrespective of his role and access.
View all and Modify all access should not be given to any regular user in the salesforce org.
Is role mandatory to create a user?
No
I want to delete 10,000 customer records but do not want anyone else to recover them. What can I do?
Salesforce makes it easy to bulk delete records permanently using the hard delete option. The difference between delete and hard delete options is that the former sends the deleted records to the Salesforce recycle bin, where it remains for 15 days. The hard delete erases all records permanently from the Salesforce system with no way to recover it.
Can you suggest a few security best practices to safeguard our critical data while using Salesforce products?
- The first security measure I recommend is enabling multi-factor authentication to add an extra layer of protection against phishing attacks, account takeovers and credential stuffing.
- I use Salesforce health check regularly to identify and fix vulnerable security settings with each new update.
- Another security measure I prefer is restricting access only to users from a designated IP address, like the corporate network. This ensures that the system denies access to hackers trying to access the system from other IPs or virtual private networks (VPNs)
As a Salesforce administrator, how would you give access to users to knowledge articles?
We can assign user knowledge license by changing the status of the knowledge user checkbox to ‘true’ on the user detail page. This ensures that the specific user has access to all knowledge articles.”
Assume a manager who oversees a team of 20 users is leaving the organization. What happens if I inactivate the manager?
The best approach is to deactivate the manager’s account and reassign the team to another manager. To prevent users from logging into the account during the reassignment, we freeze the team member’s accounts temporarily by using the “freeze” button on the user record. Once the reassignment is over, we can deactivate the freeze button and continue with the new hierarchy.
Your company specializes in providing financial consultancy services. Due to the sensitive nature of the data, you deal with, you’ve been asked to ensure that client financial records stored in Salesforce custom objects are encrypted at rest, while still allowing specific user roles, like Financial Consultants, to view the data in its decrypted form. Additionally, there’s a requirement that an automated process needs to access and process this data regularly. How would you approach this situation using Salesforce Platform Encryption?
1.Enable Platform Encryption in Salesforce.
2. Choose fields within the custom object to encrypt.
3. Assign the “View Encrypted Data” permission to the Financial Consultants role to allow them to see the decrypted values.
4. For the automated process, ensure that the user or integration account it runs under also has the “View Encrypted Data” permission so it can process the data accordingly.
1. Enable Platform Encryption: Platform Encryption is a native Salesforce feature that allows you to encrypt sensitive data at rest, meaning when it’s stored in Salesforce’s database.
2. Choose fields to encrypt: Not all fields might contain sensitive information, so instead of encrypting the entire object, you’d target specific fields that store sensitive financial data. Encrypting only what’s necessary is a best practice to ensure optimal performance and usability.
3. View Encrypted Data permission: Data encrypted with Platform Encryption is unreadable (or ‘masked’) to users by default. By granting the “View Encrypted Data” permission to the Financial Consultants role, these users can view the real (decrypted) values when they access the records.
4. Automated Process Access: By giving this user or account the “View Encrypted Data” permission, you enable the process to access and manipulate the unmasked data for its operations.
What is Connected App?
A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps.
What if user is logged in when their login hours end?
Ans. User can continue to their page but they can not do any action. Like they can not create or edit operation.
