Set up and test a group

Create a team, test membership and incident email routing, and retire the group safely.

Set up and test a group

This exercise takes a group through creation, membership changes, incident ownership, and deletion. You will use a manually created incident to check who receives email before and after a membership change.

Allow about 20 minutes. You do not need an alert or ingested data. The exercise creates real records and sends real email to the two users you select.

Before you start

Use a test account and two distinct users who belong to it:

PersonAccess neededWhat they will do
YouAccount admin or Logship.Incident.Manager; global admin also worksCreate the group and incident, change membership, and clean up
Test responderLogship.Incident.Editor, without admin or incident manager accessCheck incident access, group permissions, and email delivery

Use separate browser sessions for the two users so their permissions are easy to check. Both need access to their email inboxes.

The deployment needs a working messenger service and outbound email. An administrator can configure deployment-wide Email defaults or account-specific Email overrides. If you want to open the incident from an email, also configure the Frontend URL for incident links.

Stay in the same account throughout. Adding someone to a group does not add them to the account or grant permissions. See Group permissions for the full access rules.

1. Create the group

  1. Open Groups and select Create Group.
  2. Set Group name to Group tutorial responders.
  3. Set Description to Test team for membership and incident routing checks.
  4. Select Create Group.
  5. Copy the group's page URL, then reload it.

Check: The group name and description are saved. Members says there are no members yet. An empty group can exist, but it has nobody to notify through group ownership.

Keep the group URL for later steps. It identifies this group even if you rename it.

2. Add both users

  1. Under Members, use Add member to select yourself, then select Add Member.
  2. Repeat for the test responder.
  3. Reload the page.

Check: There are exactly two members, with an added-by user and timestamp for each. Open Add member again: neither existing member should be available to add a second time.

Membership changes save immediately. You do not need to select Save Group after adding or removing a member. They do not send membership-change emails.

In the responder's browser session, open the group URL.

Check: The responder can read the group and its members, but cannot save changes, add or remove members, or delete it. Their incident editor permission allows them to work on incidents; it does not allow group management.

3. Rename the group

In your session, change Group name to Group tutorial team and select Save Group. Reload the saved group URL.

Check: The new name is saved, the URL is unchanged, and both members are still present. In Groups, searching for Group tutorial team finds it.

4. Give the group an incident

Open Incidents and select Create Incident. Fill in:

FieldValue
Incident titleGroup tutorial - routing check
DescriptionTutorial only. Checking team ownership and email recipients. No customer impact.
SeveritySEV3
StatusOPEN
OwnerThe group Group tutorial team

Select the group explicitly; the form may initially select another owner. Select Create incident, then copy the incident's page URL.

Check: The incident is OPEN, its owner is Group tutorial team, and both members receive an Incident created email for the same incident ID. In the responder's session, open the incident URL and confirm they can read it.

Keep this incident group-owned with no individual assignee during the membership checks. An individual assignee also receives email, independently of group membership.

5. Remove a member and check routing

In your session, open the saved group URL. Select Remove on the test responder's row, then reload.

Check: You are the only remaining member. The responder is available in Add member again.

Return to the incident. Under Comments, enter:

Routing check A: posted after removing the test responder from the group.

Select Post Comment.

Check: You receive an email containing Routing check A. The removed responder should not receive that comment email. Compare the exact comment text, since emails for earlier actions may still be arriving. Once your email arrives, allow two more minutes for the responder's inbox before recording the result.

This checks new notifications only. Removing a member cannot recall email already queued or delivered. If your own email never arrives, the delivery check is inconclusive; use the troubleshooting table below.

In the responder's session, reload the incident URL.

Check: They can still read the incident and see the new comment. Their account-level incident permission is unchanged by removal from the group.

6. Add the responder back

Open the group, select the responder under Add member, and select Add Member. Reload and confirm there are two members again.

Return to the incident and post:

Routing check B: posted after adding the test responder back to the group.

Check: Both users receive an email containing Routing check B. Adding the responder back does not replay Routing check A or other past notifications.

Group membership controls the recipients of future incident notifications. It does not change the incident's owner or status. See Groups and notifications.

7. Test the deletion guard

With the incident still owned by the group, open the group page and select Delete Group.

Check: Deletion fails with an error containing:

still owns 1 incidents.

Reload the group page. It must still exist with both members. Reload the incident too; its owner must still be Group tutorial team.

Now resolve the incident:

  1. On the incident page, select RESOLVED.
  2. Enter Group tutorial: routing checks finished; testing deletion protection for a resolved incident. as the resolution note.
  3. Confirm with Save Status Change.
  4. Reload and check that the incident is RESOLVED.

Return to the group and select Delete Group again.

Check: Deletion is still blocked. A resolved incident still has an owner. The deletion guard counts all incidents owned by the group, including resolved ones.

See Group deletion rules for the underlying rule.

8. Transfer ownership and delete the group

On the resolved incident, select Reassign under Owner. Choose your own user, select Reassign, then confirm with Reassign Owner.

Check: The incident remains RESOLVED, its owner is now your user, and its URL and ID are unchanged. History records the ownership change.

Open the group page and select Delete Group.

Check: You see Group deleted. and return to Groups. Search for Group tutorial team; it should be absent. Opening its saved URL should show that the group was not found.

Open the saved incident URL once more.

Check: The incident still exists with your user as owner, and its comments and history are intact. Deleting the unused group removes its memberships; it does not delete the users or the incident.

Keep the resolved incident as the test record. There is no alert to disable in this exercise.

Record the result

CheckExpected result
CreationGroup and description survive a reload
MembershipTwo members; existing members cannot be selected again
PermissionsIncident editor can read the group but cannot manage it
RenameSame group URL and members after renaming
OwnershipGroup owns the new incident; both members receive creation email
RemovalRemaining member receives check A; removed member does not
Access after removalResponder retains their account-level incident access
Re-additionBoth members receive check B; earlier notifications are not replayed
Protected deletionGroup cannot be deleted while it owns an open or resolved incident
CleanupGroup deleted after reassignment; resolved incident retained

Record the incident URL, test date, and any failed or inconclusive checks. For a longer exercise covering alert-driven creation, mitigation, and reopening, continue with Work through a test incident.

If a check fails

SymptomWhat to check
Create or save is unavailableEnter a nonblank group name and check your account permissions. Group writes require account admin, incident manager, or global admin access.
A user is missing from Add memberConfirm they belong to this account and are not already in the group. Reload after changing account membership.
Responder can manage the groupCheck for account admin, incident manager, or global admin permissions. The permissions check requires an incident editor without those broader grants.
No creation or comment emailCheck recipient email addresses, spam folders, email configuration, and messenger availability. Incident saves can succeed even when notification publishing fails.
Removed responder receives check AVerify removal survived a reload, check the exact comment text, and confirm the responder is not also the incident's individual assignee.
Check B never reaches the responderVerify they were added back before the comment was posted. Group changes do not resend past incident notifications.
Delete is still blocked after reassignmentCheck the owner was saved as a user and look for any other incidents owned by this group, including resolved ones. The error reports how many remain.
Incident action failsCheck the current user's incident permissions and the required resolution note. See Incident Management.