Top Salesforce Interview Questions: Governor Limits, Roles, Triggers, Sandboxes, and Security
What are Governor Limits in Salesforce?
Explain the concept and why it's important.
Salesforce operates on a multi-tenant platform, meaning multiple organizations share the same infrastructure. To maintain system performance and stability, Salesforce enforces Governor Limits to control how resources like CPU, memory, and database queries are consumed.
Apex Code Execution Limits: These limits govern the execution of Apex code.
- SOQL Query Limit:
Maximum 100 SOQL queries per transaction (synchronous).
Maximum 200 SOQL queries per transaction (asynchronous).
DML Statements:
Maximum 150 DML statements per transaction.
CPU Time:
Maximum CPU time for a transaction: 10 seconds.
Heap Size:
Maximum heap size: 6 MB (synchronous), 12 MB (asynchronous).
Recursive Triggers:
To prevent infinite loops, recursive triggers have limits on how many times they can call themselves.
SOQL and SOSL Limits:
Total Records Returned by SOQL:
Maximum 50,000 records returned per query.
SOQL Query Rows:
Maximum 50,000 rows retrieved per transaction.
SOSL Query Rows:
Maximum 2,000 records returned for SOSL queries.
DML Operation Limits:
Total Number of DML Statements:
150 DML operations per transaction.
Total Number of Records Processed by DML:
Maximum 10,000 records in a single DML operation.
Callouts (HTTP, Web Services) Limits:
Total Number of Callouts:
Maximum 100 callouts per transaction (external web service or HTTP requests).
Maximum Callout Timeout:
120 seconds per callout.
Email Limits:
Single Email Messages:
Maximum 5,000 recipients per day for single emails.
Mass Email:
Maximum of 500 external email addresses per day for mass email (per org).
Future Methods:
Total Number of Future Calls:
Maximum 50 future method invocations per transaction.
Batch Apex Limits:
Batch Size:
Maximum of 200 records processed per batch.
Execution Time:
Each batch can execute for a maximum of 60 seconds.
Governor Limits on Other Salesforce Resources:
Total Number of Fields on an Object:
Maximum 800 fields per custom object.
Total Active Workflow Rules:
Maximum 2,000 active workflow rules per object.
Total Daily API Calls:
Varies based on Salesforce edition but typically ranges from 15,000 to unlimited calls per day.
Per-Transaction Basis: Most governor limits are enforced per transaction, meaning each time a trigger, batch job, or Visualforce page runs, the limits are applied to that specific execution.
Handling Limits: Developers need to carefully write efficient code, optimize queries, and use bulk operations to stay within these limits.
Error Handling: If a limit is exceeded, Salesforce throws a runtime exception (such as System.LimitException), and the transaction is rolled back.
Bulkify Code: Write Apex code that handles multiple records at a time (bulk operations), especially in triggers.
Efficient SOQL Queries: Avoid putting queries inside loops and retrieve only the required fields.
Use Collections: Leverage collections like List, Set, and Map to minimize SOQL queries and DML statements.
Use Batch Apex: For processing large data sets, use Batch Apex to handle records in manageable chunks.
Use Future Methods and Queued Apex: Offload heavy operations asynchronously to avoid synchronous limits.
Purpose: Controls data visibility within an organization, determining what records users can see based on their hierarchy within the company.
Scope: Affects access to records (rows of data) within Salesforce, often through sharing rules and the role hierarchy.
Hierarchy: Roles are organized in a role hierarchy, allowing users higher in the hierarchy to access the records owned by users below them.
Record Access: Roles determine which records a user can view or edit, often based on ownership and sharing settings.
Use Case: If a sales manager is in a higher role than a sales representative, the manager can access the sales rep’s data, but not vice versa.
Purpose: Controls what users can do within Salesforce, determining what objects, fields, and features they have access to.
Scope: Affects access to objects, fields, tabs, apps, and permissions (CRUD operations like Create, Read, Update, Delete).
No Hierarchy: Profiles are not hierarchical; every user must have exactly one profile, which defines their baseline permissions.
Permissions: A profile controls:
Object Permissions: What standard or custom objects a user can access (e.g., Accounts, Opportunities).
Field-Level Security: What specific fields on an object the user can view or edit.
App Permissions: What apps, tabs, and page layouts the user can access.
System Permissions: Controls actions like running reports, exporting data, or mass emailing.
Use Case: A sales representative might have a profile that grants access to view and edit Opportunities, while a marketing user’s profile might not grant access to the same objects or have different field-level security.
Before Trigger:
Executed before a record is saved to the database.
Commonly used to validate or modify data before it is committed to the database.
Example: Prevent a record from being inserted if a certain field is blank or invalid.
After Trigger:
Executed after a record has been saved to the database.
Commonly used to perform actions dependent on the data being committed (e.g., creating related records, sending emails).
Example: Automatically create a task after an Opportunity is closed or update related records.
A trigger can be fired based on the following events on Salesforce objects:
Before Insert
Before Update
Before Delete
After Insert
After Update
After Delete
After Undelete (used when a record is recovered from the Recycle Bin)
apex
trigger TriggerName on ObjectName (before insert, before update) {
for (ObjectName obj : Trigger.new) {
// Logic to execute before the insert or update
}
}
Trigger.new: Contains new versions of the records that are being inserted or updated.
Trigger.old: Contains old versions of the records before they were updated or deleted.
Trigger.newMap: Map of IDs to new records for update and insert operations.
Trigger.oldMap: Map of IDs to old records for update and delete operations.
Trigger.isInsert, Trigger.isUpdate, Trigger.isDelete: Boolean values that indicate which DML event fired the trigger.
Trigger.isBefore, Trigger.isAfter: Boolean values indicating whether the trigger is running before or after the DML operation.
This example checks that the “Amount” field is not negative before an Opportunity record is inserted:
apex
trigger OpportunityBeforeInsert on Opportunity (before insert) {
for (Opportunity opp : Trigger.new) {
if (opp.Amount < 0) {
opp.addError('Amount cannot be negative.');
}
}
}
This example creates a new Task after an Opportunity is inserted:
apex
trigger CreateTaskAfterOpportunity on Opportunity (after insert) {
List<Task> tasks = new List<Task>();
for (Opportunity opp : Trigger.new) {
Task t = new Task(
Subject = 'Follow up on Opportunity',
WhatId = opp.Id,
OwnerId = opp.OwnerId
);
tasks.add(t);
}
insert tasks;
}
Business Logic Automation: When you need to perform actions automatically in response to changes in your data, such as updating related records, sending notifications, or enforcing complex validation rules.
Cross-Object Field Updates: When the logic involves updating fields across different objects.
Record Validation: When standard validation rules are not sufficient to enforce specific business rules.
Complex Processes: When you need to handle complex processes that require multiple steps or involve different objects.
Bulkify Your Code: Ensure that your trigger can handle bulk operations, such as mass updates, by using collections (e.g., List, Set) and avoiding SOQL queries or DML operations inside loops.
Use Trigger Handler Classes: Move complex logic out of the trigger itself into Apex classes to keep your trigger code clean and reusable.
Avoid Recursion: Prevent triggers from recursively calling themselves, which can cause governor limit issues.
Limit SOQL Queries and DML Statements: Be mindful of governor limits when writing triggers, ensuring that you do not exceed Salesforce limits on SOQL queries or DML operations.
In more complex scenarios, you can use or implement a trigger framework to structure and organize your triggers better, allowing for more maintainable and scalable code. Frameworks help ensure that triggers are modular, reusable, and easier to manage in large projects.
In summary, triggers in Salesforce allow developers to write custom business logic that executes automatically in response to changes in Salesforce data, offering a powerful tool to automate and enforce business processes.
Q4. What is a sandbox in Salesforce?
Development: Developers use sandboxes to build and test new features, customizations, and code without risking changes to the production environment.
Testing: Sandboxes are used for various types of testing, such as:
Unit testing: Testing individual components (like Apex classes, triggers).
- Integration testing: Testing how different components work together.
- User acceptance testing (UAT): Business users can validate new features before they go live.
- Training: Sandboxes provide a safe space for training new users without affecting live data or processes.
- Data Management: You can test changes to your data structure or run large data migrations in a sandbox before implementing them in production.
- Developer Sandbox:
- Storage: Small (200 MB of data, 200 MB of files).
- Purpose: Used for individual development and testing tasks. It is refreshed with metadata but not production data (sample data may be inserted).
- Refresh Interval: Once per day.
- Use Case: Ideal for writing and testing code, building configurations, or testing small changes.
- Developer Pro Sandbox:
- Storage: Larger (1 GB of data, 1 GB of files) compared to Developer Sandbox.
- Purpose: Similar to Developer Sandbox but with more storage, making it suitable for larger development and testing projects.
- Refresh Interval: Once per day.
- Use Case: More complex development and integration tasks that require a larger data set.
- Partial Copy Sandbox:
- Storage: Medium (5 GB of data, 5 GB of files).
- Purpose: Includes a copy of your production organization’s metadata and a sample of data defined by a sandbox template (up to 10,000 records per object).
- Refresh Interval: Every 5 days.
- Use Case: Used for more comprehensive testing, including user acceptance testing (UAT), QA, and integration testing with a subset of production data.
- Full Sandbox:
- Storage: Same storage as production.
- Purpose: Contains a full copy of production metadata and data.
- Refresh Interval: Every 29 days.
- Use Case: Used for performance testing, load testing, staging, and final user acceptance testing. It is ideal for testing with a complete production data set to simulate real-world usage.
Differences Between Sandboxes:
 |
