Group Task
A Group Task in Salesforce is a single task you assign to more than one person at once, where Salesforce then creates a separate Task record for each individual recipient.
Definition
A Group Task in Salesforce is a single task you assign to more than one person at once, where Salesforce then creates a separate Task record for each individual recipient. You pick people, public groups, or queues in the Assigned To field on the New Task screen, and on save the platform expands that selection into one independent Task per user. Each recipient owns their own copy, sees it on their task list, and completes it without affecting anyone else.
There is no shared multi-owner Task record behind the feature. Assigning to a ten-person public group produces ten Task rows, each with its own OwnerId. The multi-recipient option is only available when the task is first created. You cannot edit an existing task later to add a group or extra users, and you cannot reassign a task to multiple people after the fact. The behavior is built into the standard task creation interface, so there is no special object or button to learn.
How Salesforce fans one task out to a whole team
One record per person, never one shared owner
The single most important fact about a Group Task is that Salesforce does not store one task with many owners. When you assign to several people or a group, the platform creates one Task record per recipient. Each row carries the same Subject, Due Date, Related To, and Comments you entered, but its OwnerId points to exactly one user. So a follow-up call assigned to a five-person account team becomes five distinct Task records, not one shared row five people can see. This design keeps the model simple and predictable. Every user gets a real task they can edit, reschedule, or close on their own terms. The trade-off is volume. A task sent to a fifty-person public group writes fifty rows to the Task object in a single save. The records are independent from the moment they are created, which is why a status change on one copy does not ripple to the others. Understanding this one-to-many expansion explains almost every other behavior of the feature, from reporting quirks to storage growth. Treat the group selection as a convenience for creation, not as a live link between the resulting tasks.
Assigning to people, public groups, and queues
You start a Group Task the same way you start any task. Click New Task from the Task tab, an Activity History related list, or an Open Activities related list. The Assigned To field defaults to you, so the first step is to clear that default owner. The field then lets you switch between People, Groups, and Queues and search within each. Pick the recipients you want and save. Public groups are the most common target because they bundle a stable set of users you can reuse across many tasks. Queues work too, expanding into the queue members at save time. The selection is resolved server-side, so the people on the group at the moment of creation are the ones who receive a task. Adding someone to that public group later does not retroactively give them a copy of an already-created Group Task. One practical limitation is worth noting up front. The multi-recipient picker is not available from the quick New Task action in the Activity Timeline, so use the related-list or Task-tab entry points when you need to assign to a group.
Creation only, with no later reassignment
Group assignment is a one-time event that happens only while the task is being created. Salesforce is explicit that you cannot reassign a Task to multiple users or a group after it exists, and you cannot edit a task to add new people, groups, or queues. Once the save runs and the individual rows are written, each one behaves like an ordinary single-owner task for the rest of its life. If you need to add a sixth person to a task that already went to five, the supported path is to create a new task for that person rather than expand the original. This catches many teams off guard, because the natural instinct is to open a task and tack on another assignee. That edit is simply not allowed for the group dimension. The same rule shapes how you fix mistakes. If you assigned the wrong group, you generally delete the unwanted rows and create a fresh Group Task with the correct recipients. Planning the recipient list before you click Save saves a lot of cleanup later, since there is no in-place way to broaden a task after creation.
Each copy completes on its own clock
Because every assignee holds a separate Task record, completion is tracked per person rather than per group. When one user marks their copy Completed, the other copies stay Open. There is no single state that flips to done when the last person finishes, and no built-in progress bar that shows how many of the assigned users have closed their task. A manager who expects one task with a tidy complete-or-not flag will be surprised the first time half the team has finished and the task still reads as outstanding somewhere. Reassignment follows the same per-row logic. Any individual copy can be handed to a different user or routed to a queue without touching the other copies, which is handy when one assignee is out of office and a colleague picks up their work. Comments, attachments, and status edits also live on the single row where they were made. Nothing you do to one person's copy is visible on another person's copy. This independence is the price of giving everyone a real, editable task instead of a read-only shared view.
Reporting on who finished and who did not
Reporting is where the one-record-per-person model demands the most planning. Salesforce does not stamp the resulting rows with a shared group-task identifier, so there is no out-of-the-box field that links the copies back together for a clean completion rollup. The common workaround is to give every group task a stable, unique marker you control. Many teams put a recognizable string in the Subject, or add a custom text field on the Task object and populate it at creation time, then build a report grouped by that marker. Grouping by Subject plus Activity Date plus the Who or What reference is a reasonable approximation when no custom field exists. From there a report on the Task object, filtered to your marker and grouped by status, shows how many copies are Completed versus Open. A summary report counting records by Status gives the team-level progress view that the feature does not provide natively. The lesson is to decide your tracking key before rollout. Retrofitting a marker onto tasks that were already created in bulk is painful, so bake the identifier into your creation process from day one.
Lightning, Classic, and Activity Settings
The multi-recipient task experience described here is the Lightning Experience behavior, accessed through the standard New Task screen on the relevant related lists. In Salesforce Classic, the equivalent capability is governed by a Group Tasks option in Activity Settings under Setup. Enabling it lets the New Task page accept more than one person, including public groups and roles, and Classic likewise creates one task per individual when you save. The two interfaces share the same underlying outcome, a Task row per assignee, even though the screens differ. Because the feature touches org-wide Activity Settings, only an administrator can turn the Classic option on or off. The Activity Timeline component in Lightning has its own quick New Task action, but that compact action does not expose the group picker. That is why the documented steps route you through the Task tab or the Open Activities and Activity History related lists, where the full Assigned To control with People, Groups, and Queues is available. Knowing which entry point exposes the group option avoids the frustration of looking for it in the wrong place.
Performance and storage on large groups
Every Group Task is a bulk insert in disguise, so the size of the recipient list directly affects performance and storage. Assigning to a small account team is trivial. Assigning to a several-hundred-member public group writes that many rows in one transaction, which takes noticeable time and consumes data storage proportional to the number of recipients. Those rows also land on every assignee's task list and Activity Timeline, so an overly broad assignment can clutter many users' workspaces with a task they did not really need. Treat large-group assignment as a deliberate choice rather than a default. Ask whether each person genuinely needs an actionable, independently owned task, or whether a single notification or a Chatter post would serve better. When you do assign broadly, communicate the per-user model so recipients understand that closing their own copy is all that is expected of them. Keeping group sizes sensible also keeps your Task volume manageable for reporting and storage. The convenience of one click that fans out to a whole team is real, but it scales linearly in records, and those records are permanent until someone deletes them.
Create a Group Task in Lightning Experience
Here is how to create a Group Task in Lightning Experience so one task reaches several people at once, with each recipient getting their own copy.
- Open the New Task screen
Click New Task from the Task tab, or from the Open Activities or Activity History related list on a record. Avoid the compact New Task action in the Activity Timeline, since it does not show the group picker.
- Clear the default owner
The Assigned To field starts with you as the owner. Remove yourself so the field opens up to accept multiple recipients.
- Choose People, Groups, or Queues
Switch the Assigned To control to People, Groups, or Queues and search for the recipients. Public groups are the usual choice because they bundle a reusable set of users.
- Fill in the task details and save
Enter the Subject, Due Date, Related To, and any Comments. Click Save and Salesforce writes one independent Task record for each selected user.
The recipients. Clear the default owner, then select People, a public Group, or a Queue. This selection is what gets expanded into one task per user.
What the task is. Because there is no native group-task ID, a clear and stable Subject doubles as your reporting key across all the copies.
The starting state, normally Open or Not Started. Each recipient's copy carries its own Status and is completed independently.
- The group option is creation-only. You cannot edit an existing task later to add more people, groups, or queues.
- The quick New Task action in the Activity Timeline hides the group picker, so use the Task tab or a related list instead.
- Closing one person's copy does not close the others. There is no single completion state for the whole group.
- Assigning to a large public group writes one row per member, which adds to Task storage and clutters many users' task lists.
Prefer this walkthrough as its own page? How to Group Task in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Group Task.
- Create Tasks in Bulk for Multiple PeopleSalesforce
- Enable Group Tasks in Salesforce ClassicSalesforce
Hands-on resources to go deeper on Group Task.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. When an admin assigns a Group Task to a fifty-user public group, what does Salesforce actually create on save?
Q2. A user closes their own copy of a Group Task. What happens to the other assignees' copies of that task?
Q3. Which scenario is the right fit for a Group Task rather than routing the work through a shared queue?
Discussion
Loading discussion…