As a community manager or a Salesforce admin, you may need to automatically add new users to a group on Chatter or Community Cloud.
While you can use Visual Workflow (Flow) or an Apex trigger to achieve this, the good news is: you can do the same thing with Process Builder! As Salesforce admins always say, you can accomplish many things with clicks, not code.
When new users are created, they are automatically added to a specific group on Chatter or Community Cloud.
- Working knowledge of Process Builder
- Your community is small- to medium-sized (Process Builder has scalability issues)
Create a Process in Process Builder
- Visit Setup-> Process Builder.
- Give the process a name. Under “The process starts when” field, select “A record changes.”
- Next, select an object that starts the process. Click “Add Object”, select the User object, and keep it as “only when a record is created”. Hit “Save.”
- Click “Add Criteria” and fill it in as follows:
- This next step would seem surprisingly unintuitive (I’ll expand more on this in the section below). Under “Scheduled Actions“, click “Set Schedule” and set it as the following:
- Under the same “Scheduled Actions” box, click “Add Action”. Select “Quick Actions” and give the action a name. Under Filter Search By, select “Type”, followed by “Create a Record”, and “New Group Member.” Set the Quick Action Field Values as the following:
- You’re set! Remember to activate this process.
Here’s how the final process looks:
It would be remiss of me to not test it out to make sure it actually works:
Why Scheduled Actions Are Used Instead of Immediate Actions
If you use Immediate Actions like I did and tried to create a new user, you’ll run into an unhelpful error message:
“Workflow Action Failed to Trigger Flow. The record couldn’t be saved because it failed to trigger a flow. A flow trigger failed to execute the flow with version ID xx. Contact your administrator for help.”
You may also receive a detailed flow error email that may include something like this:
“Error element myRule_1_A1 (FlowActionCall).
DML operation on setup object is not permitted after you have updated a non-setup object (or vice versa): CollaborationGroupMember, original object: User”
The User object is considered as a setup object, while CollaborationGroupMember is a non-setup object.
According to the official Salesforce documentation:
“DML operations on certain sObjects, sometimes referred to as setup objects, can’t be mixed with DML on other sObjects in the same transaction. This restriction exists because some sObjects affect the user’s access to records in the org. You must insert or update these types of sObjects in a different transaction to prevent operations from happening with incorrect access-level permissions.“
The workaround of using a scheduled action (that also executes immediately) instead of immediate action allows the process to run in a different transaction, thus making our process work.
While you can use programmatic options like Apex triggers to automate adding new users to a Chatter / Community group, declarative tools like Process Builder can do the same thing.
Great post! I tried this out but was not successful. I got an Flow Application Error saying “Entity is read-only: CollaborationGroupMember “. The flow is triggered by the Guest User who does not seem to have the permission for this. How did you solve this?
I’m not too familiar with guest profiles as I was working on a closed community, but could you add a criteria to exclude guest profiles in your process and see if that works?
AWESOME, Thanks for doing this. It was easy to replicate.
No problem at all! I’m glad to hear you found this useful! :)
But would this really work if you make sandboxes from production? The Chatter group won’t be in the sandbox, so then the process would fail if you tried to make a new user in the sandbox (e.g., for testing).
Good question! It has been a while since I last needed to use this. Our use of Chatter groups have been limited in my current org, so I haven’t needed to do testing in the sandboxes.
I think you could still test the process created in Process Builder in the sandbox (by creating a Chatter group in the sandbox), but after you deploy the process to production, you have to make sure to change the Chatter group ID in the process in production.
I think you’re right; that would work. At my work, the architect has us deploy thru multiple sandboxes, but he also doesn’t want us changing metadata in between, even for testing. So I discovered that you can use a process to call a flow, pass the name of the Chatter group (not the ID) into the flow, and then the flow can look up the group (and fail gracefully).