Hello @Dominic Foster / @Mitch Spano do you have any updates on this feature becoming GA? It seems to have been stuck in Developer Preview for a few releases? Is there any further input you need that I could help with perhaps. Thanks, Andy
Resources from the Salesforce Developers Ask Me Anything on Apex Updates + Innovations
I hope you joined us for the fantastic SFDevsAMA on Wednesday 29th November featuring @Mohith Shrivastava and @Dominic Foster. They loved answering your questions about Apex.
If you missed it, don't worry - we recorded the series and our experts have provided some great resources that our experts for you to continue your learning!
Still have questions? Post them in this thread for our experts!
@DataWeave in Apex @Salesforce Apex Hours @Apex Transaction Finalizers @Generics in Apex @User-Mode Database Operations
#Ask An Expert #CommUpdates #Apex #Apex Class #ApexDevelopment #Apexhours
Using libraries like ApexMocks is now super verbose because of the lack of generics.
With generics, this:
private static final MyService myService = (MyService) apexMocks.mock(MyService.class);
could be written as this:
private static final MyService myService = apexMocks.mock(MyService.class);
And mock verification would change from:
((MyService) apexMocks.verify(myService)).doSomething();
to
apexMocks.verify(myService).doSomething();
While saving account and I am getting an exception mentioning "Operation failed due to fields being inaccessible on Sobject Contact, check errors on Exception or Result!"
when taken out the list of fields that are inaccessible , It was observed that the field mention were either a Formula or AutoNumber, Also I am Logged in as System Admin and i have accessibility of all these fields .
ANY idea how to fix this issue . I have checked both FLS and Profile level permission
Also wanted to know if this feature is available at Global level or is still in Beta phase.
@Chris Peterson any advice here ?
Just finding this thread as I'm having the same / similar issue.
When doing DML in user mode it seems to simply behave much differently. Including relationship fields in a queried list that you then update causes a baffling issue:
List<Contact> contacts = [
SELECT Id, Account.Name FROM Contact WHERE ID = '003E100000pQ2xdIAC'
];
update as user contacts;
this results in this error:
System.DmlException: Update failed. First exception on row 0 with id 003E100000pQ2xdIAC; first error: INVALID_FIELD, Cannot specify both an external ID reference Account and a salesforce id, AccountId: []
Whereas this works just fine:
List<Contact> contacts = [
SELECT Id, Account.Name FROM Contact WHERE ID = '003E100000pQ2xdIAC'
];
update contacts;
Why would the handling of systematic read only fields (formula, autonumber, parent relationships) be different between access levels? If this means we have to strip queried lists of sobjects of all these fields to use DML with user mode, that seems like something that should be addressed.
The ability to transiently elevate a user's permissions in the context of a given user mode SOQL query or DML operation makes a lot of sense, especially if Salesforce are heading towards Apex running user mode by default and particularly for App Exchange/managed package development. I had hoped to see this coming towards GA, but the most recent material I can find is still the Developer Preview announcement from Winter '24.
Is there a plan to bring this to GA any time soon?
When using the withPermissionSetId method, I am assuming the permission set query will get counted against the limits.
Can we not count it?
Or provide a method named withPermissionSetDeveloperName(devName) and we pass the perm set name with an underscore as the devName param, in that way, we won't have to query.
Additionally, instead of using a single permission set, can we use multiple?
If not, can we have a method in which we can pass multiple permission set Id or names?
Perhaps only one method, can allow 1 or multiple comma-separated values.
While working on our AppExchange product we moved all the query and DML to with USER_Mode and like Insert as user [sobject-here] . Now we are facing very strange issue of DML statement throwing unclear error.
"common.apex.runtime.impl.dmlwithaccess.UserModeFLSDMLExceptionWithResults: Operation failed due to fields being inaccessible on Sobject [our_Object_name], check errors on Exception or Result!
We are not able to find any documentation around
UserModeFLSDMLExceptionWithResults
We double check and can confirm that we have given all the fields permission to the user as there are only 10 fields for that object.
The exception message also does not show which field has permission missing.
We tried on scratch org of summer release and preview release of winter org.
One more fact : this is happening on 2 objects and 1 object is working fine .
@Chris Peterson any advice here ?
@Nitish Kumar And @Shivdeep Kumar Yadav
I did some digging and this issue can be resolved by following steps
So this is not really a permission issue. If you making an insert call you will not face this issue but for update you will. To fix this remove all the autonumber, formula and Name field if it is auto number like {AR-00000} from the record before updating the records.
Feel free to let me know if you are getting the issue again.
FYI @Chris Peterson
Hi there - is there any update on with the elevated permissions feature might be GA?
ApexUserModeWithPermset Feedback
Dear Salesforce, please do not GA the ApexUserModeWithPermset feature.
There's system mode. There's user mode. And the ApexUserModeWithPermset feature creates this murky, new in-between state that only adds confusion to the evolution in Apex security that has happened in recent years.
If the system knows what security is required (via PS Id) to execute a DB operation, then that seems to be a prime example of when system mode should be used. I mean, the permissions currently assigned to the user certainly aren't being honored, rather the user permissions are being over-ridden and elevated, so to claim this is user mode is a bit disingenuous. Not to mention that either an extra SOQL query needs to be added to the transaction to lookup the PS Id, or the PS Id needs to be hard-coded somewhere, which is also a bad practice especially from a backup/restore perspective. (At a minimum, accepting a PS API name vs Id would be one solution that avoids both issues, yes?)
If the direction of Salesforce is to "user mode everything", then the ability to specify a PS isn't just needed within Apex, rather the same capability will need to be delivered within Flows as well, right? Would it really make sense for each flow action to specify the PS the action should run under? The system/user mode and "How to run the flow" is specified at the flow level already, wouldn't it make sense to specify a PS to execute with at the flow level as well?
What I'm getting at is there seems to be a big disconnect between the flow world and the Apex world. Flows decide security at the "front-door" and it applies to the entire transaction. Whereas Apex seems to apply security point-by-point, DB operation by DB operation. It's messy and confusing.
The general guidance we give developers today is to think about Apex code in terms of the "front doors": If it's something end-user facing like a web service or UI controller, then you need to enforce user security and use user mode. But if the code really belongs in the "system automation" domain where the code knows what needs to be done regardless of the assigned user permissions, then use system mode. And you adopt patterns for organizing code and promoting reuse that accounts for the distinction and intentional choices (with lots of "inherited sharing" for code that is truly reusable).
Personally, I like the "front-door" security model implemented by Flow and I really wish it could be modeled within Apex (and elsewhere!) as well. Imagine if I could mark-up my UI controllers with a "@Security(mode=user, permissionSet=something)" annotation, and the same security applied for the duration of the transaction, just like a flow. Likewise for annotating a trigger, batch class, scheduled job, web service, etc. You know, all the "front-door" Apex classes. (And while we're at it, let me also apply security at the Connected App level so I can better restrict what each Connected App can/can't do. Granting FLS to a user grants them access across the board via all apps the user has access to, and that's often not a good thing.)
I really wish Salesforce would shoot for a security model that's more consistent across the board. Break down those product silos, you know?
Anyhow, I do not think the ApexUserModeWithPermset feature as currently implemented moves the platform in the right direction. It's yet another tool being added to the confusing mix of options. More churn.
If I'm wrong and this feature really is a necessary step toward achieving the target goal, then revealing the grand master plan (that goes beyond just Apex!) would go a very long way to building trust and support with the developer community.
Thank you for considering this feedback.
Our application has concrete examples where very brief elevation of privileges for some queries for some users will be very helpful. However, as in the example from @Chris Feldhacker above, marking up classes with security details would be preferable to annotating individual queries, which seems much too granular and repetitive. From an OO perspective, it feels intuitive that a class should be able to state the minimum FLS rights that are required to execute its functionality.
A quick note from the AppExchange security team: The GA version of User-Mode is fully approved for AppExchange use, although not all of the relevant security scanners are fully updated yet (i.e. PMD won't support use mode syntax until the v7 release).
As a best practice use a literal AccessLevel.USER_MODE or AccessLevel.SYSTEM_MODE rather than a variable to make it easier for static analysis tools to detect what mode your code runs in. If you have a more complex scenario where you dynamically pick between the two at runtime you should be prepared to document/explain why and what safeguards you take during security review.
If you use the compile time "AS USER" or "AS SYSTEM" syntax, or the SOQL WITH clause versions you're already using a form that's easy to check via scanning and don't have to do anything special.
Hi all,
Since USER_MODE is out of beta in Spring 23, I am looking forward to change all of my FLS and object permissions checks with USER_MODE access level for all my database operations.
My question is, as an ISV, will security review accept this check? or is there something else I still need to take care of?
Thanks
Yes, User Mode was built with ISV security review as a first order priority. You can replace all manual CRUD/FLS checks with the new USER_MODE.