In which scenarios is it acceptable to intentionally bypass FLS checks and operate in a system context?
Answer
It is acceptable to bypass FLS checks and operate in a system context in the following scenarios:
1. **Creating Roll-Up Summaries or Aggregates**: When the data is not directly exposed to users.
2. **Modifying Custom Objects or Fields**: For logs or system metadata that users cannot access directly via CRUD or FLS.
3. **High-Privileged Methods**: Accessing objects that non-admin users cannot access.
4. **Guest User Access**: Denying guest users access to underlying objects in community or site solutions.
5. **Custom Objects in Your Namespace**: When using a bespoke security policy, provided it is documented as part of the AppExchange security review submission.
These scenarios should align with Salesforce's security guidelines and be properly documented.
In which scenarios is it acceptable to intentionally bypass FLS checks and operate in a system context?
Recommended Answer Update
It's acceptable to bypass FLS checks and operate in a system context in the following scenarios:
1. **Creating Roll-Up Summaries or Aggregates**: When the data isn't directly exposed to users.
2. **Modifying Custom Objects or Fields**: For logs or system metadata that users can't access directly via CRUD or FLS.
3. **High-Privileged Methods**: Accessing objects that non-admin users can't access.
4. **Guest User Access**: Denying guest users access to underlying objects in community or site solutions.
5. **Custom Objects in Your Namespace**: When using a bespoke security policy, provided it's documented as part of the AppExchange security review submission.
These scenarios should align with Salesforce's security guidelines and be properly documented.
Reasoning
The original answer was well-structured and accurate, but had minor wording issues that made it sound more formal and less conversational. I made the following improvements to align with the brand guidelines:
1. **Tone improvements**: Changed "cannot" to "can't" and "cannot" to "can't" for a more conversational tone, following the guideline to use contractions.
2. **Clarity enhancement**: Changed "is not directly exposed" to "isn't directly exposed" for consistency with conversational style.
3. **Maintained all content**: Preserved all five scenarios and their explanations without adding or removing any points.
Regarding security rules:
- **ApexCRUDViolation**: This rule directly relates to the FAQ's core topic of CRUD and FLS bypass scenarios. The FAQ discusses when it's acceptable to intentionally bypass these checks, which is exactly what this rule helps detect when done inappropriately.
- **ApexSharingViolations**: This rule is relevant because the FAQ discusses operating "in a system context" which relates to sharing violations. When bypassing FLS checks, developers are often also working with data sharing contexts, making this rule applicable to the scenarios described.