In salesforce, we have a scenario, on the trigger of the lead object we are updating some records of Campaign. But the user on the behalf of we are running the trigger does not have edit permissions on the campaign. We are not facing any issue in the update of the campaign because the trigger is running the operation in system mode. Further, we have applied for the security review and made the changes and added the check of the object isUpdatable() and after it, we are not able to update the campaign due to that check which returns false for isUpdatable().

My questions are, Can we pass the security review without applying that isUpdatable() check? if our process has the business logic to update the campaign/opportunity on the behalf of the user who doesn't have permissions on the campaign/opportunity?

If we can not pass the security review with that check then what could be an alternative for it, where one user who doesn't have permission on campaign/opportunity, performs some operation on lead/contact and we want to update the campaign/opportunity in system mode after that operation?

or is it necessary to provide the permissions of campaign/opportunity to that user?

1 Answer 1


The code does not have to apply this check in order to pass a security review. However, to pass the review you must document this as a CRUD/FLS False Positive, explaining that these field updates are necessary for whatever reason you have even when the user has no direct access to the data.

We do this with the required false positives documentation (a document you must submit as part of the review process) along with comments in the code. It might look like:

campaign.Active = false; // CRUD/FLS False Positive: the trigger's job in this scenario is to deactivate the related campaign regardless of user permissions

update campaign; // CRUD/FLS False Positive

By adding these trailing comments you ensure that the Checkmarx report's call stack code snippet includes the FLS explanation directly, which makes it easier for the Salesforce security team to complete the review knowing you have a good reason for the variation against best practice.

We use the following prefixes for the various types of false positive that appear in our code:

  • CRUD/FLS False Positive: for all CRUD/FLS issues in queries and DML.
  • Sharing False Positive: for where we need a class to be without sharing.
  • CSRF False Positive: for where the substituted data is clean and cannot actually introduce cross site issues.
  • XSS False Positive: for where the substituted data is clean and cannot actually introduce cross site issues.

In every case, we include a single line explanation (can be long) as to why it is a false positive.

NB: For multi-line statements the trailing comment needs to be on the end of the first line of the statement to get included in the Checkmarx output.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .