Sharing & Groups
Everything you create in CloudPeek starts private to you. An investigation, incident, tool, wiki page, Automation, change request or artifact is visible only to its owner until it is shared, and sharing is done through groups: you give a group access, and everyone in that group gets it.
This page covers how to share something, what each access level actually allows, who is allowed to share, and how to create and manage the groups themselves.
Sharing controls who can see things inside CloudPeek. It is separate from the permissions you grant CloudPeek on your connected tools, which govern what the AI can do inside AWS, Azure, Splunk and the rest.
What can be shared
Seven kinds of item are shareable: investigations, incidents, wiki pages, tools, Automations, change requests and artifacts. They all use the same Share dialog.
Runbooks and dashboards are not part of this model.
Who can share
Only the owner of an item can share it, plus anyone the owner has specifically given permission to share it.
- Whoever creates an item becomes its owner, and stays its owner. When CloudPeek raises an incident automatically from an alert, the owner is whoever the alert came from.
- If you can't share something, you won't see the Share button at all.
- Being in a group with Can edit does not let you share the item on to other people. Editing and sharing are separate.
- An owner or existing access manager can grant Can share to a group. Its members can then use the same Share dialog to add or remove group access, including delegating or revoking Can share itself.
Being an administrator does not let you share other people's work. Admin rights cover managing users, tenants and groups, they don't give you access to an individual investigation, incident, tool, wiki page or Automation. If you need something you don't own, ask its owner to share it with you.
If something hasn't been shared with you, you simply won't see it: it won't appear in your lists, and opening a link to it tells you it can't be found.
Sharing an item
- Open the item and click Share. The dialog is titled Share investigation (or incident, wiki page, tool, automation).
- You'll see "Choose which of your groups can see this investigation." and a list of the groups you own or belong to. Each row shows the group's name, how much it already has access to, and an Owner or Member badge showing whether you own that group or are just in it.
- Use Search groups… to find a group by name.
- Tick a group to share with it. Once ticked, the row shows the access that group will have, starting at Can view.
- Adjust the level if you need to (see below).
- Click Share with 2 groups. CloudPeek confirms with Sharing updated and a summary of what changed, for example "Shared with 1 group. Permissions updated for 1 group."
Nothing is saved until you press that button, and closing the dialog throws away your changes. The button stays greyed out until you actually change something.
Sharing an Automation, and its playbooks
Automations are shared the same way, using the Share action in the Automation's details. The difference is that an Automation usually relies on other things, and sharing the Automation on its own doesn't share those.
If the Automation uses playbooks, the dialog shows an orange Automation warning:
This Automation references these playbooks. Group members need access to inspect them and publish changes to the Automation:
Underneath is the list of playbooks it uses, and a Share required dependencies tickbox. It is not ticked by default, so if you skip it the group gets the Automation but not the playbooks behind it, and they won't be able to look through it properly or publish changes to it.
Tick Share required dependencies to give those same groups view access to every playbook in the list when you save.
This only ever adds view access. A group that already has more access to a playbook keeps it, and unsharing the Automation later does not take the playbook access away again, since that playbook may well be in use elsewhere. Remove it from the playbook's own Share dialog if you need to.
You can only pass on access you have yourself. If a playbook isn't yours to share, it's marked "(cannot be shared by you)" and the option is unavailable, with "You need permission to share every dependency before this option can be used." If CloudPeek can't check a playbook it says "(access could not be checked)" and asks you to try again. You also need at least one group ticked first, "Select at least one group to share dependencies."
Sharing an Automation does not give anyone access to the tools it uses. When the Automation runs, it still uses the tools its owner can reach, not the tools available to the people you shared it with.
Sharing a change request
A change request is CloudPeek's record of a proposed change to your infrastructure: the plan it worked out, every version of that plan, the discussion around it, the decision to approve or reject it, and the evidence from when it ran. You'll find them under Operations → Change Management.
Open the change request and use Share in the header, alongside Approve and Reject.
Sharing covers the whole change request, every version of the plan and the discussion with it, rather than one version on its own.
The two levels do different jobs here:
- Can edit lets people revise the plan and take part in the discussion.
- Can execute is the decision itself: approve or reject the change, and propose a recovery plan if one is needed.
These are deliberately separate. Giving a group Can execute lets them approve a change without letting them rewrite the plan they're approving. Someone who can revise a plan can't wave it through, and someone who can approve can't quietly change what they're approving first.
Approval always applies to one exact version of the plan. If the plan is revised, the new version needs approving again.
Sharing a change request gives access to that change request. It doesn't, on its own, make someone an approver, their account still has to be allowed to approve changes at all.
Sharing an artifact
Open the artifact from the Artifacts page to preview it, and use Share at the bottom of the preview. The preview also tells you who it's shared with already, listing the group names next to Shared with, or "no groups" when it hasn't been shared.
Only the artifact's owner can delete it. Giving a group Can edit lets people change an artifact, but never delete it, no matter what access they have.
Artifacts made inside an investigation are a special case. When CloudPeek generates an artifact in an investigation you've already shared, the groups that can see that investigation get view and edit access to the new artifact automatically, so the people working the investigation with you can work on what it produces.
That copy is made at the moment the artifact is created. Changing who the investigation is shared with later does not change access to artifacts that already exist, so share an artifact directly if you need to adjust it afterwards.
An artifact shows what it's attached to. If you can open that thing too, its name appears and you can click through to it; if you can't, the label stays unnamed and isn't clickable, so the attachment never tells you about something you don't otherwise have access to.
Choosing how much access a group gets
Click the access summary on a ticked row (Can view, Can view and edit…) to open the list of levels. They're separate options you tick, not a single choice: the row's summary updates to show the combination you've picked.
| Level | Applies to | Behaviour |
|---|---|---|
| Can view | Everything | Always on. Sharing at all grants it, and it can't be turned off. |
| Can edit | Everything | Optional, on every kind of item. |
| Can execute | Tools, Automations and change requests | Always on for a shared tool: a tool nobody can run isn't much use. Everywhere else it's a separate choice, because starting a run, or approving a change, reaches out to other systems. |
| Can share | Everything | Optional. Lets group members open this Share dialog and change which groups have access. It does not grant edit or execute access. |
What those levels mean for each kind of item:
| Item | Can view | Can edit also allows |
|---|---|---|
| Investigation | Open it and read its findings, actions and reports | Send messages, cancel a running response, rename it, change its query or status, generate a report, and attach artifacts |
| Incident | Open it and read its timeline, findings and linked items | Update the incident's details, status and notes |
| Wiki page | Open it and read its contents | Edit the page and its history |
| Tool | See the tool and how it's set up | Change how the tool is set up |
| Automation | Open it and read what it does and its past runs | Change what the Automation does and how it's set up |
| Change request | Open it and read the plan, its versions, the discussion and what happened when it ran | Revise the plan and take part in the discussion |
| Artifact | Open it and read its contents | Update the artifact |
Can execute lets people run a shared tool (including from AI agent runs), start runs of a shared Automation, and approve or reject a shared change request.
Can share delegates sharing authority without changing what the group can do with the item's contents. A group can therefore manage access while remaining unable to edit or execute the item unless those separate levels are also selected.
"Can view" on an investigation really is read-only. People can read it, but they can't post into it, rename it, change its status or generate a report. Give a group Can edit if you want them working in the investigation alongside you.
There's no "Owner" or "Full access" level. Ownership isn't something you hand out by sharing.
When someone is in more than one group
Access adds up. Each kind of access is worked out on its own, so someone gets everything their groups give them between them, not just whatever their most generous single group gives.
That means two groups can contribute different things. If someone is in one group with Can edit on an Automation and another group with Can execute on it, they can do both, even though neither group on its own allowed both.
You can't take access away by putting someone in a more limited group. Sharing only ever grants more.
Tools: visibility is chosen when you add them
Tools are the one exception to "private until shared". When you first add a tool you choose who can use it, Private (only you, the default) or Tenant ("Available to your entire tenant"), and you can pick Groups to share it with straight away.
"Visibility cannot be changed after creation." You can still share a private tool with groups afterwards, but you can't later open it up to the whole tenant.
Tools: check the Automation warning
When you share a tool, CloudPeek shows an orange Automation impact panel listing the Automations that would then be able to run that tool on their own. It updates as you change your selection. Nothing starts using the tool until someone adds it to that Automation, and access is checked again every time a run starts.
Removing access
Untick the group and save. CloudPeek confirms with "Access removed for 1 group."
Unticking removes that group's access completely, every level at once. You aren't asked to confirm, so check the row before you save.
Seeing what's already shared
Investigation, incident, wiki and tool lists show the names of the groups each item is shared with, and a +2 style count when there are more than will fit. For artifacts, open the artifact's preview and look next to Shared with.
To see it the other way round, open a group under Settings → Groups and expand its Shared entities section, which lists what that group can get to and lets you remove something from the list.
Groups
A group is a named set of people. A group belongs to your tenant, you manage who's in it from inside CloudPeek, and a group can't contain another group.
Creating a group while you share
The quickest way is from the Share dialog itself:
- Click New group at the bottom of the dialog (or, when a search finds nothing, the Create a group named "…" button).
- Give it a Name, for example "SOC Analysts".
- Under Add users, search for people by name or email and add them. You're added automatically as the owner.
- Click Create group.
The new group appears in the list already ticked, ready to share with.
Managing groups under Settings
Go to Settings → Groups, titled Group Management, "Create, rename, and retire the groups you own." The page lists your groups showing the people in them, how many people that is, how much each group has access to, and when it last changed. You can search by name and sort by Name or Recently updated.
To create a group: click Create Group, enter a Name, and submit. You start as its only member, and CloudPeek confirms with Group created.
To edit a group: click its row to open Update Group, "Manage this group's name and members. Changes apply when you save." From there you can:
- Rename it in the Name field.
- Add members by searching for people under Members.
- Remove members from the actions menu on their row. Removing someone takes away everything this group gave them access to, once you save.
- Transfer ownership with Make owner on someone's row.
An Unsaved changes note appears as you edit. Click Save Changes to apply them, and CloudPeek confirms with Group updated. Closing the dialog throws away unsaved edits.
Transferring ownership can't be undone by you. CloudPeek asks "Transfer group ownership?" and warns that you'll lose the ability to manage members and retire the group, and that you can't reverse it yourself. Only the new owner or an administrator can.
Retiring a group
There's no Delete button, groups are retired instead. Open the group and, under Danger zone, click Retire Group, then Click again to confirm.
Unshare everything first. A group that still has access to anything can't be retired, you'll see "This group is still attached to protected resources and cannot be retired." Clear its Shared entities list (or untick it in each item's Share dialog) and then retire it. Retiring is permanent: "The group cannot be restored after it is retired."
Who can manage groups
- Getting to the Groups page needs settings access for your tenant. Without it you won't see Groups at all, and the page tells you that you don't have permission. In practice, managing groups is an administrator's job.
- Creating a group needs permission too, whether you do it from the Groups page or from New group in a Share dialog.
- Adding members additionally needs permission to look up people. Without it you can still see and remove members, but you won't get a search box to add anyone.
- A group's owner manages its name, members and ownership. Everyone else is told "Only this group's owner can change its name, members, or ownership."
- Administrators can manage groups they don't own, and the dialog says so: "You are managing this group as an administrator."
- You can't always see who's in a group. If you can't, CloudPeek tells you why: "Only this group's owner and tenant administrators can see who belongs to it."
Some groups are created automatically by a chat integration, for a Slack channel for example. They're labelled Integration channel and can't be renamed or retired by anyone, including administrators.
Limits
- A group holds up to 50 people, including the owner.
- An item can be shared with up to 64 groups.
- A group name can be up to 255 characters.