Creating and managing teams (including sub-parts)

Memory is owned by a team (Teams and projects). So "who do we share what with" ends up being a question of how you shape the team. This page covers what you actually click in the Teams and Team structure menus of the console (app.aiakiv.com), along with the concept behind each.

In one line. A team is the owner of memory; sub-parts are the skeleton that decides who reads what inside it. And team structure only takes effect when you press Apply.

Team: the owner of the memory

• Signing up creates a personal team automatically. That alone is enough to save and search.
• You can make as many more as you like and invite people to turn one into memory you build together.
• Sharing, isolation, and billing all draw their boundary at the team. One team's memory doesn't leak outside it.

Creating a team

Console → Teams → 'New team', enter a name, and create. Whoever creates it becomes the owner.

• The personal team is marked 'personal' and cannot be deleted.
• Shared teams you created yourself can be removed later (see Cleaning up).

Inviting members

Open 'Manage' on the team card for the member list and the invite form. Invite by email, choosing a role.

No invitation email goes out. The other person joins by signing in to the console and accepting. It appears on their screen as "My invitations". Invite them, then tell them separately.

If there are a lot of people, go into 'Detailed management' in the member list. It supports search, multi-select, and bulk invite/remove, and you can paste emails as CSV or plain text for a mass invitation.

Setting an alias (your @ search name)

Memory is attributed by the author's email. Set an alias per team and that name shows instead of the email, and @alias finds it (Team sharing · Searching). Console → Teams → Manage → Set alias. You set your own.

Sub-parts: the skeleton that divides a team

Once a team grows, a question appears: "does every member need to see every memory in the team?" So you divide the team into parts and sub-parts, in Console → Team structure.

Team (root)
 ├─ Engineering part      ← handle · assigned members
 │   └─ Backend sub-part
 └─ Product part
     └─ Design sub-part

There is exactly one root, and it is the team itself. You don't put a second root next to it. The root decides the storage partition for everything under it, so two roots would split one team's memory into two piles that never connect to each other. Every division happens below the root, in parts and sub-parts. If you genuinely need memory that stays apart, create another team instead.

The tree can go as deep as you like. Each node takes two things.

• A handle: an @ search tag. @handle narrows search to that part of the org.
• Member assignment: who works at that node. You set a role when you assign.

⚠ This is a different axis from the team invitation role. The owner/admin/member/viewer above are roles on the team; reader and writer here are roles on that node. You invite someone into the team, then give them a node role in team structure.

You can only assign people already in the team. Invite a new person to the team first, then assign them to a node.

Reading flows from the top down

Someone at a higher node reads the memories of the sub-parts beneath it. The reverse doesn't hold. Someone lower can't see above.

So the shape of the org chart is the reading scope. When you draw the tree, place people by asking "is it fine for this person to see everything below?"

⚠ Writing does not flow down

This is the opposite of reading, and it's where the misunderstanding usually happens.

Being a writer at a higher node does not let you write into the sub-parts beneath it. The same is true if your team role is admin: the right to manage the structure and the right to save at a node are separate things.

Saving lands at a node only when you have a seat at that node directly. A seat at an ancestor doesn't count.

Product part  ← even assigned as writer here
   └─ Design sub-part  ← you cannot write here

To write into a lower part, add a writer at that part directly. Assign them to that node in team structure, give the role writer, and press 'Apply'.

Reading wide, writing narrow: the asymmetry is deliberate. Looking down from above is necessary for managing, but if anyone could leave memories anywhere, which part a memory belongs to would blur.

If saving goes to the wrong place or doesn't land at all, start by checking whether you have a seat at that node.

⚠ Nothing takes effect until you press 'Apply': the most-missed step

Creating and editing nodes on the team-structure screen is a draft. Until you press 'Apply' the effect is zero: not in search, not in node assignment.

• Unapplied changes are shown with a badge ("N unapplied changes. Apply needed").
• Only owner and admin can apply.
• If you move to another team without applying, the changes stay (with a warning).

If you changed the structure and search results or permissions look unchanged, nine times out of ten you didn't press Apply.

Cleaning up

Sub-parts: retire before you delete

For a sub-part that's been in use, retiring is the safe move. An empty sub-part (no projects, no saved events at all) is fully deleted when retired.

• You can't delete a node that has sub-parts: move or remove them first.
• If members are assigned to the node, a warning tells you their membership (access) will be revoked.

Members: remove them and the memories stay

Removing a member from a team only revokes access. The memories they left and their attribution are preserved: a team's accumulated record shouldn't vanish because a person left.

Deleting a team

Done in the Console → Teams → Manage → Danger zone tab. You must type the team name to confirm. All the team's data is permanently deleted and other members lose access. This is not reversible (Console).

Related

• What teams and projects are, and why you split → Teams and projects
• Building together and @ attribution → Team sharing
• The full console menu map → Console
• Pinning a save target per folder → Folder binding