Showing posts with label permissions. Show all posts
Showing posts with label permissions. Show all posts

Friday, November 8, 2013

Workflow and User Permissions

Q: Do workflow rules run as the user or do they run as the system?  For example, if you had a sales team associate update an opportunity and there was a workflow that fired on any opportunity edit, would the workflow update a field that the user did not have profile (or permission set) permission to update?

Q: If the workflow action reassigned ownership to another user, would it execute the ownership change despite the user's system permission of Transfer Records as false?

Q: If the workflow action changed the record type to a value, would it change the record type if the user's profile did not have access to the specific record type value?

***

My initial reaction was that workflow would run as the logged in user and would obey the user's profile and permission sets.  However upon testing, what I found was that workflow runs as the system and does not honor the user's profile or permission.  So, for the 3 questions above:

  1. Workflows run as the system and would update a field that the user did not have profile/permission set access to update
  2. Workflows will execute ownership changes on behalf of users who do not have permission to directly change the ownership
  3. Workflows will change record types in spite of profile-specified record type access.



Thursday, December 29, 2011

It is frustrating how difficult it can be to trace down permission-related issues in Salesforce.  Without any clues from the debug log regarding the sharing rules or permissions that are applied when attempting to access/edit a record, the process of elimination in debugging user permissions can be time consuming.

Thank goodness for Google.

We want to allow our sales staff to take ownership of contact records that are created in Salesforce via an integration with our accounting software.  These records, by default, are owned by a system user account, which in our current implementation, does not have a role.

Based on my initial research, I found that there were a couple "nuclear" options:

  1. Give the sales user profile, the permission Modify All for the Contact object
  2. Give the sales user profile, the permission Transfer Records
Neither of these options were appealing to me so I kept searching and finally came across this Salesforce message board:


In one of the posts where a user has paraphrased (I suppose) some documentation somewhere, this blurb got my attention:

  • "Standard Users can transfer ownership of any lead, contact, account, case or opportunity record that he/she owns or that is owned by a user below him/her in the role hierarchy (except campaigns). "

Through some testing, I've confirmed that this would potentially solve our problem, but I am still frustrated with how poor Salesforce's debugging and documentation is when it comes to permissions.  While verifying the statement above regarding the role hierarchy, I came across this official doc:


And of course:
  • "The role hierarchy is not maintained with sharing records. Instead, role hierarchy access is derived at runtime."