Six months after a call is made, somebody always asks the same question: why do we do it this way?

In most teams the honest answer is a shrug. The conversation happened — with some luck it was in chat or mail and you can find it again. In most cases the conclusion was never written down. In the worst case the person who made the call has moved to another team, or another company.

Decisions is a module in TeamHub, the team workspace app for Nextcloud. It gives a team one place to put a proposal, discuss it, lock its wording, and record who approved it and why.

The scope is deliberately narrow. It is for all those choices your team will be asked about again: budgets, hiring, vendors, tooling, process changes, architecture. Anything where the reason matters as much as the outcome.

How a team benefits

• Every outcome carries a written reason.
• The wording locks before anyone approves it.
• Proposals route themselves to the right approver.
• Every decision has its own audit trail.
• Decisions link into a tree, not a list.
• A settled question gets superseded, not overwritten.
• Nothing leaves your server.

How it works

There is one way in: Propose decision on the team's Decisions tab, or the + on the Decisions widget on the team home.

The form asks for a subject (what is the team deciding?), the context (the full proposal, in Markdown, with file attachments that become part of the record), an impact of low, medium or high, an optional level of operational, tactical or strategic, and a category. The category is what routes the proposal: each one carries its own approvers, so filing under Budget puts it in front of the finance lead without anyone having to chase.

Then, at the bottom of the form, after you have written it, it asks how the proposal should be handled:

• Finalize it now. Straight to Awaits approval. The wording locks immediately.
• Discuss it with people I pick. Opens a Talk conversation with just those people. The proposal stays open.
• Discuss it with the whole team. Posts it as a thread in the team conversation, where any member can respond. The proposal stays open.

A private discussion is genuinely private. The proposal stays out of everybody else's activity feed, message stream and decisions list until it is finalized. A direct link to it reports that it does not exist, rather than that you are not allowed to see it.

While a proposal is open, the proposer can edit it in response to feedback. That is the entire point of a discussion phase: you should be able to act on what people said without withdrawing the proposal and starting over, losing the discussion with it. Comments are threaded underneath and cannot be switched off. A discussion you can't reply to isn't one.

Finalize locks the wording, writes a snapshot of the final proposal into the team's folder as a Markdown file, and hands the proposal to the approver.

The approver, or approvers, find it in the Approve tab of the Decisions widget, carrying a count of what needs their attention, and in their personal My Work queue. They open it, read the locked text, write a reason, and press Approve or Deny. The reason field cannot be left empty.

A decision does not have to be the end of it. Link a decision to one or several tasks, and to the earlier decision it executes on, and the flat list becomes a tree: the operational call visibly hanging off the tactical decision that authorised it. Links work in both directions. When a settled decision needs revisiting, you propose a superseding decision, and the original stays in the history with the link carried forward.

The synergy: it links, it does not copy

TeamHub's rule is that it does not become another silo. Deck stays the source of truth for tasks, Talk for conversations, Files for documents. Decisions links to them and writes back to them.

• Talk. The discussion venue. A private conversation with the people you picked, or a thread in the team's own conversation.
• Deck. Link an existing card to a decision, or create one that arrives already linked. Approved decisions usually mean somebody has to do something; this is where that lands.
• Files. The finalized proposal and its attachments live in the team folder as Markdown. Readable without TeamHub, and they outlive it.
• Calendar. An approver can schedule a meeting with the other approvers of the category, pre-filled with the proposal text, and the meeting is recorded back onto the decision.
• My Work. The personal queue across every team you are in. Proposals awaiting your approval sit under Action required and can be approved or denied straight from the row. Your own open proposals sit there too, because only you can finalize them. Proposals you will be asked to approve later appear under Waiting for others, so approvals stop arriving as surprises.
• What's new. An Open proposals tab with its own count, across all your teams at once.
• Timeline. Decisions appear as dated events, with an optional overlay drawing the line from a decision to the tasks it produced.
• Advanced projects. Decisions can be attached to milestones, and an unresolved decision close to a milestone date marks that milestone as slipping in the project health widget. When a project closes, its decisions are written out as part of the closing record.
• Notifications. The ordinary Nextcloud bell, for proposals in your category, and for outcomes and comments on your own.

What a team admin or owner controls

All of it is per team, under Manage team.

• The master switch. Integrations → Decisions. Off hides the tab and the widget; on brings them back together with every past decision. New teams get it switched on in the create-team wizard, where you can untick it. Turning it off deletes nothing.
• Categories. Integration settings → Decisions. Each one gets a name, an icon, an optional description and its own approver list. Any one approver can decide; they do not all have to. A category cannot be saved with zero approvers. Create one without, and the team owner is added, because a category that routes to nobody is a decision that gets stuck. The first category is the default on the proposal form, so put the most common one first.
• Minimum role for actions. Member, Moderator or Admin, governing Finalize, Link task, Create task and Link decision. Tighten it in teams where decisions need careful curation; leave it open where everyone keeps their own thread tidy.
• Propose is always open to every member. Deliberately. Proposing is how a team surfaces a question, and restricting it defeats the point of the module.
• The level field. Off by default. Turn it on if your team genuinely thinks in operational, tactical and strategic terms. Leave it off if it would just be one more required field.

Above all of this sits one control for the Nextcloud administrator: Admin settings → TeamHub → Decisions module, which decides whether team admins can enable it at all.

Getting started

Decisions ships with TeamHub and is switched on per team. Set the categories up first: each one carries its own approver list, and that list is what lets a proposal route itself instead of being chased. The user documentation walks through proposing, discussing and approving, and the team management guide covers categories and permissions.

TeamHub installs from the Nextcloud App Store, and every decision it records stays in your own database, on your own server.

That is usually where it stops. Not because the destination is worse, but because the first day of work is unreasonable.

TeamHub 4.6.11 adds bulk import, which turns that first day into one upload. This post covers what the file looks like, how to get one out of Microsoft Teams, and what to check before you press the button.

What actually needs to move

A team in Microsoft Teams is a name, a description, a set of owners, a set of members, and some tabs. Almost none of that is precious — it is just tedious to recreate. The messages themselves are a separate question, and worth being honest about: bulk import moves the structure, not the chat history.

In practice that matters less than it sounds. Old chat is usually kept for compliance rather than for reading, and it can stay where it is, or be exported to archive storage, while day-to-day work moves. What people need on Monday morning is their team, their people and their files — not last March's thread about the printer.

So the goal is narrow and achievable: every team exists in Nextcloud, with the right people in it, on day one.

The file

Bulk import reads a CSV with eight columns:

The separators are forgiving. The file can be comma, semicolon or tab separated, and cells holding several values accept either semicolons or vertical bars — which matters more than it sounds, because a Dutch or German Excel export is semicolon-separated by default and would otherwise need fixing by hand.

The template column is the one worth thinking about, because it decides which modules a team starts with. Three options:

• project — for work with a start and an end. Phases, milestones, budget and time.
• collaboration — for a group that works together continuously without a delivery date.
• department — for a standing organisational unit.

If you are not sure, collaboration is the safe default. Modules can be switched on later per team; nothing here is a one-way door.

Getting the file out of Microsoft Teams

The Teams admin centre will give you a team list, but not in this shape. The reliable route is Microsoft Graph, which can enumerate groups and their members directly:

Connect-MgGraph -Scopes "Group.Read.All", "User.Read.All"

$teams = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/groups?`$filter=resourceProvisioningOptions/Any(x:x eq 'Team')"

foreach ($team in $teams.value) {
  $owners  = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/groups/$($team.id)/owners"
  $members = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/groups/$($team.id)/members"
  # emit one CSV row per team
}

Two mismatches will bite you, and both are better handled in the export than in TeamHub:

1. Microsoft Teams allows several owners. The import takes one. Pick a rule and apply it consistently — first alphabetically is fine — and put the remaining owners in the members column so nobody loses access. They can be promoted afterwards.
2. Team names travel badly. Ampersands, slashes and emoji are common in Teams names and are not all valid in TeamHub. Sanitise on the way out, and keep a record of what you changed, because someone will ask why "R&D — Q3" is now "R-D Q3".

It is worth writing a second file at the same time: a warnings list of teams with no owner, teams with several owners, names that were changed, duplicates, and accounts that could not be matched. That file is what you send to the department heads before you import anything.

The migration is not the hard part. Agreeing who owns what, before you press go, is the hard part. A warnings file turns that from a meeting into an email.

The dry run

This is the step that makes the whole thing safe, so do not skip it.

Upload the file and TeamHub validates every row without creating anything. It resolves each owner and member against real Nextcloud accounts and tells you which ones it could not find. It flags duplicate team names. It shows you exactly what will exist when you confirm.

Typical first-run findings, in rough order of frequency:

• People who left, still listed as members
• Accounts that exist in Microsoft Entra but were never provisioned in Nextcloud
• Two teams that turn out to have the same name once you strip the emoji
• A department that has been quietly dead for a year

None of these are import problems. They are the inventory you never had, and it is much cheaper to see them here than after 200 teams exist.

One deliberate piece of leniency: a row asking for advanced projects without an active licence becomes a basic project instead of failing. One missing licence does not stop the run.

Pressing the button

Confirm and the teams are created with live progress. Limits are 500 teams and 2 MB per file, which is a lot of teams — and if you have more, split the file by department and run it more than once. There is no harm in several runs.

You get a results CSV at the end with the outcome of every row. Keep it. It is the answer to "did Marketing actually get created?" three weeks later, and it is the thing you attach to the change record.

The flow, end to end:

1. Export from Microsoft Graph to CSV
2. Fill the template column and fix the warnings
3. Upload and dry run
4. Confirm
5. Keep the results CSV

Realistically the export and the cleanup take an afternoon. The import itself takes minutes.

Why this matters beyond convenience

There is a reason we built this rather than writing a migration guide and wishing people luck.

The argument for self-hosting is rarely lost on the merits. It is lost on switching cost. If leaving a hyperscaler means a quarter of manual work, most organisations stay where they are and keep paying — not because they think it is right, but because the exit is priced out of reach. That is not really a technology decision.

Removing that first day of clicking is the point. Your teams end up on hardware you own, under AGPL-3.0, with no seat count and no vendor able to change the terms — a sovereign solution your organisation actually controls, and one you can leave again if you want to, since the export is a CSV too.

That last part is deliberate. A migration path that only runs one way is just a different kind of lock-in.

Getting started

Bulk import lives in Admin settings → TeamHub → Import/Export, and there is a sample CSV there to match your columns against. Full detail is in the 4.6.11 release notes, and the documentation covers the column formats in more depth.

If you are sizing a migration and want a second opinion on the export, get in touch — we would rather help you plan it than watch it stall at the spreadsheet.