Feature Request: Unified Resource Mapping to Projects

Is your feature request related to a problem? Please describe.
I'm often frustrated by the fragmented nature of managing projects across different Nextcloud apps. Emails, tasks, files, calendar events, and contacts all live in their own silos, making it difficult to see the full picture of a project. There's no unified way to group or track everything related to a project in one place, which hinders collaboration, documentation, and traceability — especially in professional or regulated environments.

Describe the solution you'd like
I’d like to see a system-wide feature in Nextcloud that allows users to assign any item (email, file, calendar event, contact, task, deck card, etc.) to a project. These projects act as lightweight, app-independent containers. Each project would have its own dashboard displaying all linked resources, and each app would offer context menus or UI actions like "Attach to Project…" for simple linking. This should be implemented as a central core functionality, accessible and extensible by all apps.

Describe alternatives you've considered
I've tried using tags, shared folders, Deck boards, and external tools like Notion or Asana to track project contexts, but none of them integrate deeply across all Nextcloud apps. They also fail to link diverse resource types (like emails and files) in one consistent view, and often require duplicate documentation effort. Third-party integrations break the self-hosted privacy model many users value in Nextcloud.

Additional context
This feature would significantly improve project-centric collaboration, enable natural project documentation, and reduce context-switching. It would serve as a milestone in Nextcloud’s evolution — from a suite of independent tools into a truly integrated collaboration platform. It also directly addresses documentation and traceability needs in commercial and regulated environments.

So, let's dive into it.

Problem Statement

Nextcloud offers a powerful ecosystem of productivity apps — Mail, Calendar, Deck, Contacts, Files, Tables, Tasks, and more. However, there is currently no native way to link these disparate resources to a common project context.

This leads to:

Fragmented workflows: Users must jump between apps to keep mental track of what's related.
No single source of truth: There’s no central view that shows all conversations, files, events, and tasks associated with a specific project.
Redundant effort: Without interlinking, collaboration becomes error-prone and inefficient.

By contrast, modern collaboration tools (e.g. Asana, Notion, ClickUp) allow users to logically map data and tasks from multiple sources into cohesive project workspaces.

Proposed Solution

Introduce a system-wide "Project Resource Mapping Layer", enabling users to attach any object (e.g. email, calendar event, contact, deck card, task, file, etc.) to a Project. Each Project is a lightweight, app-agnostic organizational unit (OU) acting as a hub for linked resources.

This feature would be implemented as a core-level module or officially supported app, with deep API hooks and UI extensions available to other apps, whether first- or third-party.

Key Features

Contextual Linking in Every App
- Right-click or action menu in Mail, Files, Calendar, Contacts, Deck, Tasks, Notes, etc. includes: "Attach to Project...".
- Select existing project or create new one inline.
Centralized Project Dashboards
- Each project has a dashboard that aggregates all linked items.
- Sections for Emails, Files, Tasks, Events, Contacts, Deck Cards, etc.
- Each entry deep-links to its native app.
- Create new items (Tasks,Deck/Cards,Events, etc.) from Dashboard at point of interest
Thread- and Object-Aware Mapping
- Link a conversation thread → future replies included.
- File updates, event changes, task completions → all reflected in dashboard view.
System-Wide Hub Architecture
- The mapping system exists as a shared service used by all apps.
- Includes a unified resource model and internal API.
- Optional sync connectors or logic extensions for apps with complex resource states (e.g., versioning or threads).
UX Patterns
- Consistent and lightweight project picker (with recent projects, search, and favorites).
- Badge or icon indicating project affiliation.
- Inline contextual preview when hovering or tapping the project reference.
Smart Suggestions & Automations
- Predictive assignment: Based on metadata (e.g., sender, tags, filenames), recommend relevant projects.
- Optional rules: Auto-linking based on folders, templates, or pre-defined triggers.
Permissions & Sharing Respect
- Linking doesn’t override native app permissions.
- Projects show a warning if a linked item is inaccessible to some team members.
Extensible via API
- Well-documented public API for developers to implement project linkage in their own apps.
- Webhooks and events for automation.
Export Project Reports / Archives
- Ability to export a report with KPI's, Graphs, whatever is useful in terms of project management
- Ability to export optionally selected data into an archive file

Strategic Impact: A Milestone for Nextcloud as a Collaborative Platform

This feature would represent a major milestone for Nextcloud by transforming it from a collection of powerful individual tools into a cohesive, workflow-oriented collaboration suite.

It enables users to structure their work across apps with clarity and control — a feature largely missing in self-hosted ecosystems.
It closes a long-standing gap in cross-app context management, allowing for intentional workspaces around real-world projects.
It enhances focus and accountability by giving users a clear place to go for “everything related to X.”

In doing so, it would position Nextcloud as a true contender to established SaaS platforms, without sacrificing user sovereignty or privacy.

Why It Matters for Business & Documentation

In professional and regulated environments, teams face increasing pressure to:

Document decisions, responsibilities, communication threads, and deliverables.
Prove traceability of actions and correspondence across projects.
Provide audits of who knew what, when, and why — across systems and data types.

With this feature:

A project dashboard becomes a living documentation space, where every linked resource is contextually embedded and automatically updated.
Even informal actions (like an internal mail or calendar reschedule) become part of the traceable project history — without additional effort.
Organizations gain a highly valuable compliance and knowledge management layer, baked directly into the flow of work.

This directly answers key documentation and traceability questions for teams in:

Software development and DevOps
Construction and architecture
Legal and audit-heavy industries
Public sector and regulated markets

No additional systems are required — documentation emerges naturally as teams collaborate.

Success Criteria

To fulfill its potential, this feature must:

Be fully integrated into all major first-party apps.
Provide a low-friction UI and consistent cross-app behavior.
Be implemented as a core component or officially supported infrastructure module to ensure maintainability and extensibility.
Match the reliability and UX polish of best-in-class SaaS tools.
Be future-proof, enabling integrations with external systems (via Flow, API, webhooks, etc.).

Conclusion

This is not just a feature — it is an architectural leap forward. It turns Nextcloud into a platform that organizes not just data, but collaboration itself.

By building in a unified, context-rich, project-aware layer, Nextcloud gains:

A better user experience
A strategic advantage in collaborative environments
A tangible answer to documentation and traceability challenges for serious, professional users

Projects are not silos — but the glue between the things we do and the way we work.

Please use the 👍 reaction to show that you are interested into the same feature.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.

Hello,
I am trying to achieve the same goal but with a different approach.
I try to identify key aspect of the Nextcloud project which could enhance the project management without a major overhaul of the Nextcloud project. I am trying to write some feature request in different part of the ecosystem.

What I am trying to achieve is a global project management system within the Nextcloud ecosystem.

The key apps that will be used.
=> Circles app ( To manage the project teams)
=> Collectives (Where the users will work on the project)
=> Calendar (embedded in the collectives) (Milestone already achieved with few bugs)
=> Deck (embedded in the collectives) (Milestone already achieved with few bugs)
=> Chat (not embedded)
=> Tables app ( for centralizing all the projects into a table)
=> Mail (I am trying to ban mail and use chat for project management)

For the moment, each individual project can live happily into their own collectives, the centralization part is really missing. (Tables app)
I have set few feature request which could change all the centralization and the permission part if they get implemented.
I think your feature request is too vague and look like generated with an AI which makes it difficult to understand how it will be achieved

Might have some relevance: https://github.com/nextcloud/related_resources

@joshtrichards

@joshtrichards technically, the feature request does match what you have linked, but with additional functionalities or convenience. Thank you.

@Aveyron-RetD the feature request is indeed vague on purpose. I tried to put the spotlight on the bigger picture instead of getting too technical.

Consider this as a kind of kickstarter for collecting ideas in order to make this idea like something of value for the project.

CC @nextcloud/designers

@DrDBanner

@DrDBanner => The tables app has merged two commits that brings my vision closer to what I was saying above to do with Nextcloud.

I hope the Nextcloud team or a volunteer can tackle the last features requests and I will be able to centralize projects in tables. While keep everything smooth for the teams.

nextcloud/tables#1340 => By doing this i can keep each collectives completely separated while they share for exemple the same contacts table or the same table for projects management. This would allow me to create a collective as a template and inside this collective there would be already those tables. I would just have to create a new collective on a new project and they would be ready to go.🎺

=> After I can create bespoke views for managing all the projects at once 🎺

I can highly recommend taking a look at Teams. They in combination with Tables/Collectives should already cover 80-90% percent of your requirements.

Indeed, deck + collectives + Chat seems to cover all your needs for one team.
But when user is part of multiple teams, and you want to share things you end up back to less flexibility.

For example deck board works well for one team but multiple board with multiple teams ?
nextcloud/deck#7543

Collectives works really well for one team, but again you cannot share your work that easily with other teams.
nextcloud/collectives#2308

Tables seems getting better and better but I have not introduced it yet.
But for belonging to multiple teams there is still some work todo...
I have re-worded the feature request. nextcloud/tables#1340

Maybe this feature request of embedded stuff being restricted to files and folders would solve many of those sharings problems.

Just to make sure: One Deck board can be shared with multiple teams, on the "Upcoming Cards" page you see all cards from all boards you have access to. The issue you mentioned is quite special I would say - it is not uncommon to have let's say "department boards" and "project boards" separated.

Regarding Collectives: Teams can be members of other Teams. A collective needs one Team in the background, yes, but if you create a fresh Collective you can add other Teams as members.

I do not think my use case is quite special.
Yes some boards are unique to a team, but it is not uncommon that you want to share this one card access to people because all your work is on it.
The same is true for collectives pages.

Its kind of never ending story. If you end up sharing everything, we are back to square one. Why did you need permission at all and create circles and teams.
My permissions are mainly to reduce infobesity. People do not need access to everything it makes things clutter and harder to find the info.

Sorry for this wall. I have the feeling it's necessary to get the whole picture.
tl:dr; Don't fix at app level. Fix at core level.

Core Workspace Resource Layer for Projects, Teams, Provisioning and Pre-Configuration

Relation to the existing Project Resource Mapping proposal

This proposal should be understood as a continuation and extension of #53125.

That issue already describes a core problem very well: project-related work is fragmented across Nextcloud apps. Emails, files, calendar events, contacts, tasks, Deck cards and other resources live in their respective app silos, and there is no consistent system-wide way to attach them to a common project context.

The proposed “Project Resource Mapping Layer” is therefore an important and correct direction.

However, resource mapping only solves one side of the problem.

It answers the question:

Which existing resources belong to this project or context?

But team and workspace operations also need to answer a second question:

Which resources should exist for this team or workspace in the first place, how should they be configured, who should receive them, and how should their state be maintained over time?

That second part is not solved by simply adding more UI on top.

Why a core workspace resource model is the better solution

A TeamHub-like interface can make team work visible. It can provide a home view, widgets, links, messages and app entry points.

But if the underlying resources are still created, owned, configured, shared and repaired independently inside each app, the UI can only hide the fragmentation temporarily. It cannot solve it structurally.

Without a shared platform layer, every workspace UI has to implement app-specific workarounds for questions such as:

Which folder belongs to this team?
Which Deck board is the team board?
Is this calendar mapped to the team or only manually shared?
Are indirect team members allowed to see the resource?
Was this resource created by the workspace, or manually mapped later?
Which mail signature policy applies to this team?
Which Tables context belongs to this workspace?
What happens when a user joins or leaves the team?
How can broken shares or missing subscriptions be repaired?

These are not cosmetic UI questions.

They are platform questions.

A cosmetic layer can provide navigation. It cannot reliably provide ownership, provisioning, pre-configuration, lifecycle management, permissions, repair or auditability.

That is why the underlying target model should not be “add more special cases to TeamHub” or “make each app look more integrated”.

The better target model is a shared core resource/context layer that apps can implement against.

Mapping is necessary, but not sufficient

The existing project mapping proposal is about linking existing resources into a project context.

This proposal adds provisioning and pre-configuration.

Both are needed.

A useful workspace layer should support:

1. Map existing resources
2. Provision new resources
3. Pre-configure resources from templates
4. Apply team/workspace policies
5. Expose the workspace context to native apps
6. Detect and repair drift

Example:

Workspace: Sales
 ├── map existing group folder "Sales"
 ├── map existing Deck board "Sales Pipeline"
 ├── create new Talk room "Sales"
 ├── create new team calendar "Sales Appointments"
 ├── provision Tables context "Sales CRM" from template
 ├── map address book "Sales Contacts"
 └── apply mail signature policy "Corporate Sales"

A pure mapping layer would know that these resources belong together.

A provisioning and pre-configuration layer would additionally know how to create them, configure them, assign them, maintain them and repair them.

That is the missing operational layer.

Why this matters for TeamHub

TeamHub should be seen as a consumer of this platform capability, not as the place where the whole problem should be solved.

TeamHub can provide the team-centered surface.

But Nextcloud core, or an officially supported infrastructure layer, should provide the common model for:

resource identity
resource ownership
mapped vs provisioned state
workspace membership
app resource providers
permissions and policy hints
widget/activity providers
native app deep links
lifecycle and repair

This would make TeamHub more reliable and also make the same infrastructure available to other apps, project dashboards, CRM-like workflows, Tables contexts, automation, reporting and future workspace interfaces.

Goal of this proposal

The goal is not to build a monolithic CRM or ERP.

The goal is to avoid another layer of visual integration that leaves the underlying app silos intact.

The goal is a shared Nextcloud workspace resource model that connects:

project resource mapping
team workspaces
provisioning
pre-configuration
app context awareness
lifecycle management
repair and drift detection

In short:

#53125 describes how resources can be attached to a project.

This proposal describes how a project/team/workspace can also define, provision and maintain the resources it needs.

Together, both ideas form a stronger target model than cosmetic UI integration alone.

Summary

Nextcloud already has many strong building blocks for team collaboration and lightweight CRM-like business workflows:

Teams / Circles
Files
Talk
Calendar
Tasks / CalDAV tasks
Contacts
Mail
Deck
Tables
Pages / Collectives / IntraVox-like apps
Activity
Notifications
app-specific sharing and permissions
DAV/CardDAV/CalDAV tooling
existing discussions around Tables contexts

The gap is not that none of these features exist.

The gap is that there is no single core-level model for:

which resources belong to a team/project/workspace
whether a resource was mapped or provisioned
how resources should be pre-configured
which defaults apply
which policies apply
how native apps understand the current workspace context
how onboarding/offboarding should affect workspace resources
how broken or inconsistent resource state can be repaired

Core concept: Workspace Resource Layer

Introduce a core Workspace Resource Layer.

It should represent a project/team/workspace as a first-class organizational context.

Example:

Workspace: Sales
 ├── files.folder: /Teams/Sales
 ├── talk.room: Sales
 ├── calendar.calendar: Sales Appointments
 ├── tasks.list: Sales Follow-ups
 ├── contacts.addressbook: Sales Contacts
 ├── deck.board: Sales Pipeline
 ├── tables.context: Sales CRM
 ├── pages.space: Sales Wiki
 └── mail.policy: Sales Mail Defaults

Each resource entry should record:

app identifier
resource type
resource ID
workspace/project/team ID
mapped vs provisioned status
ownership metadata
access policy metadata
open URL / deep link
optional widget provider
optional activity provider
provisioning status
repair status

This would generalize the idea from the initial post and make it usable not only for manual project linking, but also for team/workspace provisioning.

The missing second half: provisioning and pre-configuration

The existing Project Resource Mapping idea is necessary, but it should not stop at mapping already existing resources.

A workspace model also needs to describe the intended state of a workspace.

That means:

Workspace state is not only:
- these resources are linked

Workspace state is also:
- these resources should exist
- these resources should be configured in this way
- these resources should be available to these users/teams/roles
- these defaults should apply
- these policies should be inherited
- this state should be repairable

This requires a provisioning and pre-configuration model in addition to resource mapping.

Proposed provisioning target model

A team/project/workspace should be defined declaratively.

Example:

workspace:
  id: sales
  name: Sales
  type: team-workspace
  principal:
    type: team
    id: sales

resources:
  files:
    mode: map
    resource: groupfolder:sales
    path: /Teams/Sales
    preconfigure:
      folder_structure:
        - Customers
        - Offers
        - Contracts
        - Templates
    policy:
      inherit_from: team
      allow_external_sharing: false

  talk:
    mode: create
    name: Sales
    preconfigure:
      type: team-room
      description: Sales team communication
    policy:
      membership_sync: true

  calendar:
    mode: create
    name: Sales Appointments
    preconfigure:
      default_reminder: 30m
      default_visibility: team
      auto_subscribe: true
    policy:
      inherit_from: team

  tasks:
    mode: create
    name: Sales Follow-ups
    preconfigure:
      templates:
        - Call customer
        - Send offer
        - Schedule meeting
      default_reminder: 1d
    policy:
      inherit_from: team

  contacts:
    mode: map
    resource: addressbook:sales-contacts
    preconfigure:
      auto_mount: true
      default_contact_groups:
        - Customers
        - Suppliers
        - Partners
    policy:
      sales_member: write
      sales_intern: read

  deck:
    mode: map
    resource: deck:sales-pipeline
    preconfigure:
      columns:
        - New
        - Qualified
        - Offer
        - Won
        - Lost
      labels:
        - Hot Lead
        - Existing Customer
        - Follow-up
    policy:
      inherit_from: team

  tables:
    mode: create
    template: sales-crm
    preconfigure:
      context_name: Sales CRM
      tables:
        - Companies
        - Opportunities
        - Activities
      views:
        - My Opportunities
        - Open Follow-ups
        - Management Overview
    policy:
      inherit_from: team

  pages:
    mode: create
    template: sales-wiki
    preconfigure:
      pages:
        - Home
        - Playbook
        - Meeting Notes
        - Templates
    policy:
      inherit_from: team

  mail:
    mode: configure
    preconfigure:
      sender_identity: sales@example.org
      signature_template: corporate-sales
      variables:
        - user.displayName
        - user.jobTitle
        - team.name
        - organization.name
      default_folders:
        sent: Sent
        archive: Archive
    policy:
      allowed_senders: team:sales
      enforce_signature: true

This model is intentionally declarative.

It should describe the desired workspace state, not only perform one-time setup actions.

Resource modes

Each resource should support one of several modes:

create
  Create a new resource for this workspace.

map
  Attach an already existing resource to this workspace.

configure
  Do not create or map a primary resource, but apply workspace-related defaults or policies.

skip
  This workspace does not use this resource type.

disabled
  This resource type is explicitly disabled for this workspace.

Examples:

Files:
  map existing group folder

Talk:
  create new room

Deck:
  map existing board

Tables:
  create new context from template

Mail:
  configure team signature and sender identity policy

Contacts:
  map existing address book

This distinction is important because real organizations often already have existing folders, calendars, boards, contacts or mailbox structures.

A provisioning model must not assume that every workspace starts from zero.

Provisioning is not only creation

Provisioning should mean more than creating a resource.

It should include:

- create resource
- map existing resource
- configure resource
- assign access
- sync membership
- apply policies
- apply defaults
- apply templates
- expose deep links
- expose widgets
- expose activity
- validate state
- repair drift

A one-time “create resources” wizard would not be enough.

The platform needs a durable intended-state model.

Pre-configuration requirements

Pre-configuration should be first-class.

Admins should be able to define defaults before users start working.

Files

- default folder structure
- default permissions
- external sharing policy
- retention hints
- workspace root

Talk

- default room name
- default room description
- membership sync from team
- default announcement/support rooms

Calendar

- default calendar name
- default reminders
- default sharing
- auto-subscription
- default visibility

Tasks

- default task list
- task templates
- default reminders
- workflow states
- follow-up defaults

Contacts

- default address books
- team address books
- auto-mount behavior
- read/write policies
- default contact groups

Deck

- board templates
- columns
- labels
- card templates
- permissions
- default board views

Tables

- context/application templates
- schemas
- views
- relations
- permissions
- widget sources

Pages / Knowledge

- workspace homepage
- playbook template
- meeting notes template
- policy pages

Mail

- centrally managed signatures
- team-specific signatures
- role-specific signature variables
- sender identity defaults
- mailbox/delegation mapping where supported
- default folders where supported
- signature enforcement policy

Mail is a good example why this matters.

It is not enough that individual users can configure signatures.

Organizations need team-wide communication standards, for example:

Team: Sales
 → sender identity: sales@example.org
 → signature: Corporate Sales Signature
 → variables:
    {user.displayName}
    {user.jobTitle}
    {team.name}
    {organization.name}
 → policy:
    enforce signature
    allow only Sales members to use identity

That is not cosmetic UI integration.

That is organizational pre-configuration.

App-specific role of the layer

This layer should not replace app functionality.

It should provide the shared context that apps can implement against.

Teams / Circles

Teams/Circles should become first-class principals for workspace context, mapping and provisioning.

Needed:

stable team identifiers for resource mapping
lifecycle events when users join or leave a team
support for direct and indirect membership where appropriate
consistent interpretation of team membership by integrated apps
repair tooling for team-resource mappings
policy inheritance from team/workspace roles

Files

Needed:

map or provision team folders
support group folder mapping
support existing folder mapping
expose folder deep links
provide workspace-scoped file widgets
apply team permissions consistently
repair missing access or stale shares

Talk

Needed:

map or provision team rooms
sync room membership from team/workspace membership
expose unread status and recent activity
connect Talk room to the workspace registry

Calendar

Needed:

map or provision team calendars
apply default sharing/subscription behavior
open native Calendar in workspace context
avoid unrelated calendars by default when launched from workspace context
repair missing subscriptions or shares

Tasks

Needed:

map or provision task lists
expose open tasks widget
connect tasks to workspace/project resources
optionally link tasks to Deck cards, Tables rows, contacts, files or calendar events

Contacts

Needed:

map or provision team address books
distinguish personal address books from workspace address books
optionally connect contacts to mail, calendar, deck, tables and files
repair missing address book access or subscriptions

The system address book is not enough for this use case because it represents users of the instance and is not a freely managed external CRM/customer address book.

Mail

Needed:

map team mailbox/delegated mailbox where supported
apply team signature templates
apply sender identity defaults
enforce or suggest team-wide communication standards
expose mail context where technically possible
remove or update mail-related permissions when users leave the workspace

Deck

Needed:

map or provision boards
support board templates
expose board/card widgets
preserve native Deck behavior while adding workspace context
repair missing or inconsistent board access

Tables

Needed:

map or provision Tables contexts/applications
provision schemas/views from templates
expose workspace-relevant views as widgets
extend the existing Tables context idea toward workspace provisioning

Pages / Collectives / IntraVox-like apps

Needed:

map or provision page spaces
provide team homepage/playbook/meeting-notes templates
expose page activity and deep links

Activity / Notifications

Needed:

aggregate activity from mapped/provisioned resources
keep workspace activity scoped
avoid mixing unrelated personal activity into workspace views unless explicitly requested

Policy inheritance

Workspace resources should inherit policies from the team, group, role or workspace template.

Example:

Sales Member:
  read/write Sales contacts
  read/write Sales Deck board
  read/write Sales Tables records
  use Sales mail signature
  use Sales sender identity

Sales Intern:
  read Sales contacts
  create tasks
  read Sales calendar
  no delete permission
  no shared sender identity

Sales Lead:
  manage Sales workspace
  manage Deck board
  manage Sales calendar
  manage Tables views
  manage members

Policies should define:

- read
- write
- delete
- share
- administer
- send-as / use identity
- enforce default
- allow override
- allow unsubscribe/hide
- membership sync
- ownership transfer
- offboarding behavior

Native app context

Apps should be able to receive and understand workspace context.

Example:

/apps/files?workspace=sales
/apps/calendar?workspace=sales
/apps/deck?workspace=sales
/apps/tables?workspace=sales
/apps/mail?workspace=sales

The app can then decide how much of that context it supports.

Minimum expected behavior:

focus the mapped/provisioned resource
show that the resource belongs to a workspace
avoid confusing unrelated resources where possible
provide a way back to the workspace

This would make TeamHub and similar interfaces much more reliable without turning them into app-specific workaround layers.

Resource provider API

Apps could expose a standard provider interface.

Example:

ResourceProviderInterface:
- listMappableResources()
- mapExistingResource()
- createResource()
- configureResource()
- assignAccess()
- syncMembership()
- removeAccess()
- getOpenUrl()
- getWidgetData()
- getActivity()
- getProvisioningStatus()
- repair()

This is not meant to flatten all apps into one model.

It is meant to provide the minimum common contract for workspace orchestration.

Lifecycle model

The provisioning layer should react to membership and workspace lifecycle events.

Onboarding

User joins Team: Sales
 → assign Sales workspace
 → reveal or mount Sales folder
 → join Sales Talk room
 → subscribe Sales calendar
 → reveal Sales task list
 → mount Sales contacts
 → reveal Sales Deck board
 → reveal Sales Tables views
 → reveal Sales pages
 → apply Sales mail signature defaults
 → apply sender identity policy

Offboarding

User leaves Team: Sales
 → remove inherited access
 → remove Talk room membership
 → remove calendar subscription/share
 → remove Deck board access
 → remove Tables access
 → remove address book access
 → remove sender identity permission
 → preserve organizational records
 → transfer personally owned workspace resources if required

Workspace archival

Workspace is archived
 → make resources read-only
 → preserve files and records
 → disable new activity
 → keep audit/history
 → optionally hide from active workspace lists

Repair and drift detection

The provisioning model must be repairable.

A workspace should have an intended state, and Nextcloud should be able to compare that intended state to the actual app state.

Possible checks:

- resource missing
- resource deleted
- resource exists but is not mapped
- resource mapped but inaccessible
- missing share
- stale permission
- missing team member access
- indirect team membership not resolved
- missing calendar subscription
- missing address book availability
- Deck board visible in TeamHub but not in Deck
- outdated mail signature template
- missing sender identity policy
- Tables context exists but views are missing
- widget provider unavailable

Possible commands:

occ workspace:list
occ workspace:status sales
occ workspace:provision sales
occ workspace:repair sales
occ workspace:sync-members sales

occ workspace:map-resource sales files <resource-id>
occ workspace:map-resource sales deck <resource-id>
occ workspace:map-resource sales calendar <resource-id>
occ workspace:unmap-resource sales tables <resource-id>

occ workspace:template:export sales
occ workspace:template:import sales-workspace.yaml

This makes the workspace model operationally useful.

Without repair and drift detection, provisioning becomes another one-time wizard.

Difference between mapping and provisioning

The distinction is important:

Mapping:
  "This existing resource belongs to this project/workspace."

Provisioning:
  "This workspace should have these resources, with these settings, policies and lifecycle behavior."

Pre-configuration:
  "These resources should start with these defaults, templates, views, signatures, reminders, columns and permissions."

Repair:
  "The actual state should be checked against the intended state and corrected where possible."

All four are needed.

#53125 primarily describes the mapping side.

This proposal adds the provisioning, pre-configuration and repair side.

Relationship between Projects, Teams and Workspaces

The exact naming can be discussed.

The important point is that Nextcloud needs a shared context object.

Possible terms:

Project
Team Workspace
Workspace
Context

#53125 uses “Project” as the common container.

TeamHub uses the existing “Team” concept as the visible workspace entry point.

Tables already discusses “Applications / Contexts”.

These concepts should not evolve into incompatible models.

They should ideally share one underlying resource/context layer.

For example:

Context
 ├── Project
 ├── Team Workspace
 └── Tables Application

or:

Workspace
 ├── project-type workspace
 ├── team-type workspace
 └── app/context-type workspace

The naming matters less than avoiding another silo.

Non-goals

This proposal does not ask for:

a monolithic CRM
a full ERP
replacing TeamHub
replacing Teams/Circles
replacing Feature Request: Unified Resource Mapping to Projects #53125
removing personal resources
forcing every app to implement every feature immediately
forcing every resource into a workspace

Personal resources should continue to work.

The proposal is about a shared layer that apps can gradually adopt.

Expected outcome

Nextcloud gains a platform-level resource/context model.

#53125 can use it for manual project resource mapping.

TeamHub can use it to display and operate team workspaces reliably.

Tables contexts can align with it instead of becoming a separate silo.

Admins can define and pre-configure team/project workspaces.

Apps can expose resources, widgets, activity and provisioning status through a common contract.

Users get coherent workspaces instead of manually assembled app silos.

Example:

Team: Sales
 ├── TeamHub home
 ├── Talk room
 ├── Files
 ├── Calendar
 ├── Tasks
 ├── Contacts
 ├── Deck
 ├── Tables
 ├── Pages
 ├── Mail defaults
 └── Activity

Final statement

TeamHub shows the need for team-centered workspaces.

The initial post describes the need for project-centered resource mapping.

The missing platform piece is a shared core layer that supports both:

mapping existing resources to a project/team/workspace
provisioning and pre-configuring new resources for that context

Without this shared layer, every app and every workspace UI has to solve resource context, ownership, access, widgets, activity, lifecycle and repair in its own way.

With this layer, Nextcloud can move from a collection of integrated apps toward a coherent collaboration platform without becoming a monolithic CRM or ERP.

@DrDBanner

Sorry too long for me this post @DrDBanner did you try https://apps.nextcloud.com/apps/teamhub

@Aveyron-RetD

@Aveyron-RetD

My post is addressing teamhub.

I wrote literally: tl:dr; Don't fix at app level. Fix at core level. - which sums it up. You can't fix with apps what's missing to become coherent.

So this manual linking was introduced with Nexcloud 16 in 2019: https://nextcloud.com/blog/nextcloud-16-allows-you-to-link-resources-to-keep-track-of-your-projects/

We removed it, as it was not used much. The problem is that it is manual work. Later, we added related resources, which automatically connects resource across Nextcloud. It works on a heuristic: if a resources is shared with the same group of people as another, they are related. Check the sharing sidebar of a file, a Deck card, a Talk room and so on - you see resources you have shared with the same group of people there.

This is something most people probably never found, and of course the link is relatively weak. And you could not see them all in one place, like a dashboard, either.

In the meantime, Circles was developed to allow non-admins to create custom groups.

We then combined Related Resources and Circles in Teams in 2024. So teams were associated with resources, but it's still just shared. We created an overview of teams, and the resources shared with them.

But ownership of resources is a key point, and that's what we are tackling now with the latest work on Teams. With that will come some views of the resources in one place, but we haven't fully decided how to do that. The approach of basically rebuilding other Nextcloud apps in the Teams app is not very sustainable, embedding whole apps is slow and Dashboard widgets are not interactive/powerful enough. How else to do it is something we will find out in the coming releases.

I would propose we close this issue. The resource mapping to projects is a feature we had - and abandoned. The central organizing model will be Teams, going forward. If you have suggestions for Teams not currently covered, you can submit them, but I am actually quite convinced that the roadmap already covers your needs quite well: nextcloud/circles#2664

@jospoortvliet

Thanks @jospoortvliet, this helps a lot.

I think we are actually quite close on the underlying idea, but there is one conceptual difference that I believe is essential. I agree that manual resource mapping is not a good foundation. If users first have to discover a feature, understand its mechanism and then maintain relationships manually, limited adoption is not surprising. But for me this is not primarily a discoverability problem. It is a question of what the system considers the primary structure of work.

As I understand the current Teams direction, work is organized around a group of people. A Team becomes the collaboration and ownership container, and resources are associated with it. This solves important problems around shared ownership, access and continuity. What I am describing starts from a different point. In many business scenarios, the primary structure is not the group of people, but the subject of the work itself: a customer, project, case, contract or another persistent business context.

This becomes important as soon as the same people work on more than one subject. The same Team may handle ten customers and twenty projects. A heuristic based on resources being shared with the same group of people can identify a possible relationship, but it cannot determine which business context those resources actually belong to. An email, a file and a meeting shared with exactly the same people may still belong to three completely unrelated projects.

A context model starts with that missing information. The project, customer or case is the subject. Resources belong to it because they are part of that subject. People, Teams, permissions and ownership can then naturally be attached to the same context. A project can have a Team. A customer can have several Teams. A case can have responsible people, owners and external participants.

The reverse requires introducing the context again. If the same Team works on ten projects, the Team itself cannot distinguish between them. Another entity is needed to represent each project. If every project, customer or case is instead represented as a separate Team, then Team effectively becomes a substitute for that missing business context rather than representing only the people collaborating.

That is the structural difference I am trying to preserve: Teams organize resources around actors. Contexts organize actors and resources around the subject of the work. As soon as the same actors work on more than one subject, the first model alone cannot express that distinction without introducing the second dimension again.

This is why I see Teams as a very strong foundation, but not necessarily as the complete model for structured business work. A context can naturally include Teams, ownership, permissions and collaboration. A Team alone cannot express what the work is about and why a particular set of resources belongs together.

How this should be implemented technically is not something I can or want to prescribe. Teams, Circles, Related Resources or something else may provide most of the technical foundation. The people working on Nextcloud are much better positioned to decide that.

What matters to me is that the design does not stop at organizing resources around people if the goal is to support work that is actually organized around customers, projects, cases or similar subjects.

If this additional context dimension is already part of where Teams is heading, then I think the concepts converge very well. In that case I am completely fine with closing this issue. My concern is not keeping the issue alive. It is making sure that the distinction between organizing the people doing the work and representing the actual subject of their work does not get lost.

Cheers
dros

Hello dros,
I already read through your initial posts wich much interest. Another point that will come up in the discussion an refinement of teams in the future is working on tags. They are a feature that isn't mature enough yet, but might cover this horizontal mapping of ressources. What do you think?

@alimmroth

@alimmroth should this not be in nextcloud/circles#2664

@Aveyron-RetD

@Aveyron-RetD it should, but that topic has still flown a little bit under the radar. I have already discussed it with @marcoambrosini and will bring it up after the 35 release.

@alimmroth

Hey @alimmroth, thank you. I think tags can be useful for horizontal mapping, but I would not use them to reconstruct the context itself.

For me, the more important question is what Nextcloud chooses as the primary organizing concept. If the primary entity is the context, Teams, members, ownership, permissions, resources and tags fit into it naturally. A project, customer or case may define such a context, but the important concept is the context itself.

If the primary entity is the Team, additional mechanisms become necessary as soon as the same people work across multiple contexts. Tags can then help classify or map resources, but they are effectively being used to recreate information that the model did not represent in the first place.

That is where I see the structural difference. For communication centered collaboration, organizing around people and Teams can be very natural. For structured business work, the Team is often a participant in the work, not the subject of it.

Context first naturally includes Teams. Team first has to reconstruct context afterwards.

That is why I would still argue for a business first perspective. Not because Teams or tags are wrong, but because the choice of the first class concept determines how naturally the rest of the model can grow around it.

That is where I see the structural difference. For communication centered collaboration, organizing around people and Teams can be very natural. For structured business work, the Team is often a participant in the work, not the subject of it.

I see the point, but the challenge is that almost all organizations already VERY much organize around teams. As I said, we tried projects in the past but the manual nature of assigning them meant it went unused - same issue as tagging: people just won't bother with it. I really don't believe in it.

This becomes important as soon as the same people work on more than one subject. The same Team may handle ten customers and twenty projects. A heuristic based on resources being shared with the same group of people can identify a possible relationship, but it cannot determine which business context those resources actually belong to. An email, a file and a meeting shared with exactly the same people may still belong to three completely unrelated projects.

I think you underestimate teams. They ARE meant to be projects. You can create a team for each project, and attach the resources. Heck, you can use a team with only yourself in it as a way to organize things if you want - share stuff with it, easy to track it. We hid shared items for the 35 release but that should come back.

So a team is both a context and a group of people who works IN that context. You can have dozens of teams. And with the same people. Each new contract, each partner that is managed, each survey, CAN be a team, they can be very lightweight. They aren't meant to be as heavy as in SharePoint or MS Teams.

You don't have to do it that way, there are tools to organize smaller tasks and projects, of course. But I don't think there is per-se a need for another concept that is so much overlapping. I think it just makes things more complicated. And you'd have to assign thing to two entities - a team and a context...

I understand the reasoning, including the concern about manual assignments and user adoption. But I think you're addressing concerns I haven't actually raised. My remarks were specifically about the underlying data model, not whether Teams can be used to organize projects. Whether you call an entity a team, project, or context doesn't change its underlying semantics or relationships. And distinguishing concepts at the model level doesn't imply that users must manage them separately or manually. In modeling, seemingly minor distinctions can have significant consequences for real-world usability, provisioning, and long-term maintainability.

That's precisely why I argued for addressing this at the core level rather than solving it through individual app conventions.
Just my two cents.

Feature Request: Unified Resource Mapping to Projects #53125

Description

Problem Statement

Proposed Solution

Key Features

Strategic Impact: A Milestone for Nextcloud as a Collaborative Platform

Why It Matters for Business & Documentation

Success Criteria

Conclusion

Activity

Aveyron-RetD commented on May 27, 2025

joshtrichards commented on May 27, 2025

DrDBanner commented on May 27, 2025

provokateurin commented on Jul 7, 2025

Aveyron-RetD commented on Sep 8, 2025

ericfischereu commented on May 5, 2026

Aveyron-RetD commented on May 5, 2026

ericfischereu commented on May 6, 2026

Aveyron-RetD commented on May 6, 2026

DrDBanner commented on May 7, 2026

Relation to the existing Project Resource Mapping proposal

Why a core workspace resource model is the better solution

Mapping is necessary, but not sufficient

Why this matters for TeamHub

Goal of this proposal

Summary

Core concept: Workspace Resource Layer

The missing second half: provisioning and pre-configuration

Proposed provisioning target model

Resource modes

Provisioning is not only creation

Pre-configuration requirements

Files

Talk

Calendar

Tasks

Contacts

Deck

Tables

Pages / Knowledge

Mail

App-specific role of the layer

Teams / Circles

Files

Talk

Calendar

Tasks

Contacts

Mail

Deck

Tables

Pages / Collectives / IntraVox-like apps

Activity / Notifications

Policy inheritance

Native app context

Resource provider API

Lifecycle model

Onboarding

Offboarding

Workspace archival

Repair and drift detection

Difference between mapping and provisioning

Relationship between Projects, Teams and Workspaces

Non-goals

Expected outcome

Final statement

Aveyron-RetD commented on May 7, 2026

DrDBanner commented on May 7, 2026

jospoortvliet commented on Aug 26, 2026

DrDBanner commented on Aug 27, 2026

alimmroth commented on Aug 27, 2026

Aveyron-RetD commented on Aug 27, 2026

alimmroth commented on Aug 27, 2026

DrDBanner commented on Aug 27, 2026

jospoortvliet commented on Oct 25, 2026

DrDBanner commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels