Changing Account ownership isn't just a simple switch — it can ripple through related objects like opportunities, cases, attachments, and contacts. You might bump into permission hiccups or issues with related records. Moreover, identifying these issues' root cause may be challenging...😨
➡️ Dive into our Knowledge Article to learn more and make your transitions smoother than ever!
Hello, we are trying to deactivate the account of a user who has left our organization, and we are getting a "Error: This user is the default owner of records created by guest users and can’t be deactivated." message. Directions provided on the internet are fruitless because it leads us to site settings but we don't have any sites. I think it is referring to how this user is the default owner for NPSP/IATS records for donors and donations. But I cannot find where to change that owner so I can deactivate the account. Please help. Thank you! #NPSP #IATS #Record Owners
Hi Tirthna,
We have it configured under Setup > Sites then 'Edit' the iATS site. You can change the default owner on that screen.
Hi all!
In our Org we setted the sharing rules for Service Appointment to private and make the right setting in order to let the Engineers have visibility only to Dispatched Service Appointments in the Field Service App.
Currently we have in place a process which requires the Engineers to book a Service Appointment through the action "book appointment" in the Salesforce 1 app, once the Appointment is created it has "Scheduled" as status and the Eng is able to see it since he is the owner. In order to avoid the Engineer to see the record we have created a Process Builder that changes the owner of the record, conditions are only the status and the created by profile. When the PB is active and we try to book an appointment, we receive an error that says "List has no rows for assignment to SObject". Do you have any idea why we are receiving the error? or do you have any suggestions on how we can avoid the Engineer to see the just created record?
Many thanks!
Sara
not sure specifically on the error. I'm wondering if it has something to do with the fact that when going through the Appointment Booking Action, SA records are committed to the database, but as there is a potential to roll back if a slot is not selected. I know you can update values during that action, with something like a before save flow but maybe there is something more with trying to update the Owner Field Specifically.
Have you tried using something like an after save flow vs a PB to see if the result is the same? Or possibly update the criteria to only fire once a scheduled start/end has been set on the SA? This would assume that the action has gone all the way through the process, slot selected, and then scheduled.
Also, which Object is the Engineer using Book Appointment on?
Hey Everybody,
Kind of a specific question here, but can Record Owners create pre-defined case teams or can only admins do that? I am a still bit new and haven't found it spelled out in the documentation.
Hi All,
I am trying to find any documentation related to applying row level security to external data.
We basically have a dataset that's coming from an external source and we want to apply row level security so just record owners can see the data in Einstein.
I know the basic idea is to have a field in that external data that can be used to create a link with SF user data and drive security.
I just want to know if there is any documentation related to a case like this or if any of you have experience achieving the same.
Thanks!
One thing that I believe should be available in Wave/Einstein is that you could give access to a Dashboard but not to the Dataset.
It comes handy when you have a Dashboard that's used by a large population and you don't want them to use the Dataset to create their own lenses without the business logic that was applied to the Dashboard.
Wrong data starts flying around and some users could start questioning if the data is accurate.
Topic #Clarification needed on the privileges of Record Owners:
My understanding is that:
Record owners have full access to the records that they own.
Full access means that they could read, edit, delete and share that record.
To confirm this I created a record of an object and then assigned ownership of that record to a user that only had Read object level access. Then I logged in as the owner.
The owner could only see the record and not edit. When I added edit object permissions, they could then edit.
So, do object level permissions always filter out records and restrict what a user can do to that record, even if owned by the user?
Ok... got the answer. Mayank Srivastava helped me think through this. Here is the 9 yard - worth a read!
Munira, think of Profile permissions to be the baseline permissions in Salesforce. They control what you can or cannot do with records. If an owner user's profile has Read access to an object's recod, they can only Read it. If they have Read +Edit , they can Read and Edit the record and not do anything further (Create , Delete).
"Record owners have full access to the records that they own" - This is in regards to the Sharing Setting. So it an be interpreted as:
Record owners have full access to the records that they own and what they can do with the record is defined by their Profile object permissions.
So, you can give a user full access to Cases for Public Read/Write/Transfer but if their Profile permissions only grants them Read permission, the sharing rule won't be able to bypass that.
My improved understanding after Mayank's help:
Thanks Mayank, as always.
Thinking aloud:
Literature on Salesforce has been hammering in my mind that Record Owner has FULL ACCESS to the Record they own. FULL ACCESS literally means - Create, Read, Edit and Delete right on a Record. Logical and common sense.
But this monkey wrench - Object Permissions of CRED needed by the Record Owner, in conjunction with the Record Owner's "FULL ACCESS", to work - will take some time to get absorbed :(
Although Record Owner has "FULL ACCESS" to the Records they own, Object Permissions on a User's profile determine what a Record Owner can do with the records they create and own (hmm... counterintuitive).
So, basically, in other words, Record Owner's "FULL ACCESS" privilege is worth a cent only if they ALSO have CRED permission for that particular Object on their Profile!!
I think that Layers of Rooms analogy (one room inside another) is at work here:
What one can do with a Record, even if one is owner/creator of that Record, will depend on what object permissions for the object, in which that record resides, one has on the Profile!
Thanks Mayank again!! GREAT help!!
