function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jlhmitchelljlhmitchell 

How is contact ownership defined (defaulted) when contact created by community user?

I have case-trigger based behavior that will assign a case team member to a case based on a value on a field (exposed and editable by community users). If a contact doesn't exist, the contact is created prior to adding to case team.

This works fine, unless the account owner of the community user is an inactive user. In that scenario, the contact is not created.

I have tried to set the ownerID of the contact on create, but debug is showing me that the failure is still occurring with 
INACTIVE_OWNER_OR_USER, operation performed with inactive user [<Account Owner ID>] as owner of contact: 

My suspicion is that salesforce defaults to account owner ID, but allows on creation a different value (I can verify that the ownerID I set for contact is otherwise used when on an account that is not owned by an inactive user).

Is there something I am missing? Does anyone have suggestions? 
 
Best Answer chosen by jlhmitchell
Andy BoettcherAndy Boettcher
Check it out!  New profile permission!

http://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_general_audit_fields_inactive_owners.htm#rn_general_audit_fields_inactive_owners

All Answers

Andy BoettcherAndy Boettcher
Check it out!  New profile permission!

http://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_general_audit_fields_inactive_owners.htm#rn_general_audit_fields_inactive_owners
This was selected as the best answer
jlhmitchelljlhmitchell
Andy, that's brilliant (hadn't seen this in the release notes), but it looks as though community (actually in our case, we're repurposing portal) profiles cannot be assigned this system permission.

I confirmed this by enabling the organization user permissions in sandbox, verified that a standard profile can now be granted the Update records with inactive owners, but a profile we use in community does not see this permission.

I've confirmed that the community user is the user in context while creating the contact record. My brain is stuck in a loop: I thought that contact ownership is defaulted to the user who creates the contact. It makes sense that portal/community users can't be the owner of a contact, but what is driving that the account owner defaults to be the owner? Why can't I force a different owner? I've even tried creating the contact without an account initially (with the thought I could update the contact to assign account after creation), but the owner still persists to be the owner of the account related to community user.

I also tried doing all of this as a lead and converting the lead (I can force ownership and existing account during lead conversion), but the community user cannot perform lead conversion (it also seems a convoluted way to get to the intended result). 

By the way, our sharing settings for contact is "Controlled by parent" so perhaps THAT's the answer for why it adopts the account's owner. But that doesn't explain why I am unable to create a contact without an account relationship at all, yet the account ownership still persists.
jlhmitchelljlhmitchell
Hm. I realized while I was typing the above that while I had tried not setting the accountID, I hadn't actually pushed a null value to accountID on the contact. So, I did that (pushed accountID to be null when contact first created along with a specific ownerID, then updated contact to assign accountID).

Interestingly, this does seem to work BUT I can see on the contact record's chatter feed that the owner is being changed from account owner to pushed owner prior to the account being changed from null to the assigned value.

I halfway wonder whether the act of enabling the organization user permission caused different behavior. I didn't test after making that change because I was unable to assign the profile permission so assumed it made no difference. 

I am going to move the code change to another sandbox and test the heck out of it. If the code change alone doesn't enable the behavior, I will also enable the organization user permission and see if that enables behavior differences.

I will report back my results either way.
jlhmitchelljlhmitchell
Preliminary testing shows that the code change is indeed irrelevant. Possibly the only thing enabling this to work is the organization setting change to enable 'Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions'. Still testing
jlhmitchelljlhmitchell
Final result: checking the option 'Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions' allows the context user in trigger to borrow from some user who can update records with inactive owners, so this actually solves for the initial problem. Thanks, Andy!!
Andy BoettcherAndy Boettcher
Boom boom shake the room - AWESOME!