When teams track work in Nextcloud Deck and Tables
Teams that track work in spreadsheets, chat threads or a separate SaaS board often ask whether Nextcloud Deck and Tables can take over part of that load. The short answer is that they can cover lightweight team tracking inside the platform that already holds your files, and the fit depends on how deep your workflows go and how much reporting you need. Before you move anything, write down the handful of tasks a typical team runs each week, the places where those tasks live today, and the people who need to see them. That inventory shows which parts of the work can move and which should stay where they are.
Deck is the kanban board app in Nextcloud. Its boards are organized into stacks and cards, and cards can carry assignments, due dates, comments and file attachments drawn from the same storage your team already uses. Tables is the structured data app, so it suits records that need defined columns and consistent fields, such as an intake register or a simple request log. The two apps answer different questions: Deck shows where work stands, and Tables holds the structured records behind it. Confirm on your release which card features, board sharing options and Tables column types are available, because both apps change between releases and depend on the versions your administrators install from the app store.
This page is about implementing Deck and Tables for team work, not a general product tour. It covers the decisions that shape the rollout: which teams get boards, how board sharing maps to the groups and users your directory already defines, where card attachments are stored and who can see them, and how Tables data is kept apart from files that follow a different retention rule. Other pages in this series cover adjacent areas such as shared folder design and wiki editing, so treat those as separate decisions that affect this one. The sections that follow take these decisions in order, starting with the pilot.
Start with a pilot that uses one team and one real workflow for several weeks. Ask your platform team to confirm that Deck and Tables are enabled in your release, check which app versions they can install, and verify that sharing and permission behavior matches your access model. Record what the team actually uses, such as whether cards need dependencies, recurring tasks or time tracking, and confirm whether each of those needs is supported. Where a need is missing, that gap is where a dedicated project tool may still fit better. Make that comparison against the team's written requirements and a feature list, not against a demo.
Plan for two risks before the pilot grows. The first is ownership: a board or table created by one person can outlive that person's role, so decide who administers each board and who may change its structure. The second is data drift. When the same work is tracked in a chat thread, a spreadsheet and a board at once, the board stops being the record and status becomes unreliable. Set a short rule for each team that states where the status of a task is kept, review that rule at the end of the pilot, and include it in onboarding for new members so the board remains the single place people check.
What Deck and Tables do inside Nextcloud
Deck and Tables are two Nextcloud apps for tracking team work next to the files they relate to. Both reuse the sharing, attachment and user model of the rest of the platform, so the access decisions you make for files and groups carry over to boards and tables.
Deck boards, stacks and cards
Deck organizes work as boards containing stacks, which are columns such as backlog, in progress and done, and cards that move between them. Each card can carry labels, an assignee and a due date, and can be discussed through comments. Before rollout, map your team's existing workflow onto stacks and decide who may create boards, since the stack layout is what most teams will see every day. Confirm the current card fields and board options against the Deck documentation for your release.
File attachments on cards
Cards can reference files stored in Nextcloud, so a task can point to the contract, specification or design that it depends on. The attached file keeps its own sharing and permissions, which means a person who can see the card but not the file cannot open it through the card. Test this with a user who holds card access only, and agree a rule for whether teams attach copies or links to the source file.
Tables for structured rows and columns
Tables provides a structured data grid where you define columns, enter rows and save views that filter or sort the same data for different readers. It suits registers such as vendor lists, risk logs or intake requests, where a board would lose the detail that teams need to compare items. Decide early which registers belong in Tables and which belong in Deck, because mixing both for the same work creates two sources of truth.
Sharing through the platform user model
Boards and tables are shared with users, groups or teams using the same mechanism as files, so membership in Nextcloud groups or Team Folders determines who sees what. Changes to directory groups, whether synced from LDAP, OpenID Connect or SAML, flow through to these apps without per-board edits. Review sharing on a sample board and table after your identity integration is live, and confirm how sharing to external guests behaves in your release.
Notifications, comments and audit trail
Comments on cards and changes to assignments generate activity that users see in Nextcloud, and mentions can alert a colleague who is not watching a board. Activity history is useful for reviews, but it is not a substitute for a formal audit log. Ask your administrators which server logs and activity records are retained, how long they are kept, and whether your retention policy covers them.
Dependencies and limits to validate
Deck and Tables are community apps with their own release cycles, so their features and compatibility can differ from the core server. Check each app's entry in the Nextcloud app store against your target major version before upgrading, and disable both until they are confirmed compatible, as the upgrade guidance recommends for third-party apps. Ask for the documented limits on board size, attachment handling and table columns, rather than relying on how a pilot happened to perform.
Configuration decisions before the first board goes live
This table compares the seven settings that shape how Deck and Tables are adopted, with the options for each, when each fits and what it affects later. Read each row before creating the first board, because several choices are hard to reverse without moving content or rewriting permissions. The main takeaway is that sharing scope, attachment location and deletion ownership decide most of the cleanup work later.
| Decision | Options and when each fits | What it affects later |
|---|---|---|
| Who creates boards | Any user: fits teams that already self-organize and want low friction. Admins only: fits regulated teams that need board creation tied to an approved request. Confirm how your version restricts app access by group. | Board sprawl, ownership of abandoned boards and how often admins must intervene to clean up. |
| Board sharing scope | Individual, group, circle or public link. Individual fits private work. Groups fit a department. Circles fit cross-team projects. Public links fit only content that may leave the organization. | Who can see card contents and attachments, and whether removing one person later requires editing many boards. |
| Boards per team or per project | Per team fits standing work such as operations queues. Per project fits bounded initiatives with a clear end date. Many teams use per team boards with a label or stack per project. | Board count, how easily work is archived at project close and how reporting across projects is done. |
| Tables or spreadsheet or board | Tables replaces a spreadsheet when rows are structured records with fixed columns. A board fits when work moves through stages and needs assignees and due dates. Use both when a Table holds the register and a board tracks active items. | Whether data lives in one place, how easily users can export it and whether two sources of truth drift apart. |
| Attachment storage location | Deck attachments stored in the user's files fit small teams using personal folders. A dedicated folder, often a Team Folder, fits shared work and retention rules. Confirm where attachments land in your version before users upload. | Who owns the files when a person leaves, which retention and quota policies apply and how easily an administrator can find attachments. |
| Guest access for external collaborators | Guest accounts fit short external projects with a named sponsor. Share links fit one-off file exchange. Avoid external access to boards that hold internal planning data unless the sharing rules are reviewed. | Who can see board content after a contract ends, how guest accounts are reviewed and whether guest activity is covered by your access reviews. |
| Retention and deletion ownership | Board owner deletes: fits small teams with clear owners. Administrator deletes: fits regulated records. Define whether deleted cards, archived boards and attachments follow the same rule. | Whether records survive staff changes, how backups and trash handling affect deletion and which retention evidence you can show an assessor. |
Setting up boards, tables and existing task data
Decide the structure of boards and tables before anyone creates content in them. Most later clutter comes from choices made in the first week: how boards are named, which stacks represent workflow states, and which labels people may use. Agree a naming pattern that includes the team and the purpose, such as the team name followed by the work type. Define stacks once, for example to do, in progress, review and done, and keep the same column order on every board in a team so that people moving between boards do not relearn the layout. Keep the label vocabulary short and closed. A small set of labels maintained by one person stays usable, while labels created ad hoc by individual users fragment reporting and filtering within a few months. Give every board a named owner who approves changes to stacks and labels and who answers for who has access.
Board access should follow the same group structure that controls the related files. Deck boards can be shared with individual users, groups and circles, and Tables are shared in a similar way, so decide which principal grants access before you start. Where a team already has a Team Folder, align the board's group with the group that holds the folder's permissions. If a board is shared to a different set of people than the folder that holds its attachments, you will get one of two failures: people see a card whose attachment they cannot open, or people see project details for files they were never meant to reach. Share through groups rather than individual accounts wherever possible, so that a change in team membership is made once in the directory or group settings. Confirm how guest accounts and external shares behave in your app version before you invite anyone outside the organization.
Moving existing tracking data in is usually the most time-consuming part of setup. Start with an inventory of each spreadsheet or tool: its owner, its columns, how many rows it holds, whether it links to files, and whether it carries comments or status history. Map every column to a target. A title, description, due date or assignee generally maps to a Deck card field, while structured numeric or status data is usually better suited to a Tables column of the right type. Columns with no clear target need a decision: drop them, merge them into a description, or create a new table column. Bulk import paths differ between Deck, Tables and app versions, so confirm which import method your installed version supports, whether it is a file import, an API route or a scripted process, and test it on a staging copy with a small sample before any production load.
Decide what history you keep, because most import paths will not carry over the full history of a spreadsheet. Version history, cell comments and the edit trail of the original tool usually stay behind. Choose between importing only the current state, which keeps the new boards clean, and keeping an archive copy of the original file in a restricted Team Folder for audit or reference. If you keep the archive, give it the same access as the source data, not the wider team. Then check sensitive content against the access model before cutover. Tracking sheets often contain personal data, customer identifiers, HR details or security incident notes, and attachments on imported cards land in files with their own permissions. Run an access review on the target boards, tables and the folders that hold their attachments, confirm that backups cover both the application data and the files, and test a restore of one board before retiring the old tool.
How a Deck and Tables rollout runs, step by step
The sequence moves from a confirmed platform baseline to a pilot on live work, then to a rollout with named owners. Each step ends with a written output, so the platform owner and the pilot team can see what is settled and what still needs a decision. Use it as a checklist for your own team or as the scope a partner quotes against.
Confirm the Nextcloud release and app availability
The platform owner checks which Nextcloud release is running or planned and confirms that Deck and Tables can be installed on it from the app store your organization allows. Confirm the release line against the Nextcloud maintenance schedule, and plan any server upgrade before pilot work begins. Nextcloud requires upgrades one major version at a time, with a backup taken first. Check that no third-party app in the same instance conflicts with the install. Output: a short compatibility note, signed off by the platform owner, listing the release, the app versions and the install method.
Define the pilot team and work types
The team lead and the platform owner choose one pilot team and list the work types it will track in Deck and Tables. Examples might include recurring operational tasks, internal requests or small approvals (illustrative). Record which work stays in a dedicated project tool, so the boundary is clear from the first day of the pilot. Name a sponsor who can settle disputes about scope. Output: a pilot charter that names the team members, the sponsor, the work types in scope and the work types excluded.
Design board and table permissions
The platform owner and the pilot lead design each board and table: stacks or status columns, labels, table columns, field types and the attachments each card carries. Map who can view, edit and manage each board, using the users, groups and circles your sharing model allows. Confirm each option on your release, because sharing and table features can differ between versions. Output: a board and table specification plus a permissions map that lists each board, each table and the roles that touch it.
Configure sharing and attachment locations
The administrator sets where card attachments are stored and who can reach them. Decide whether attachments sit in a team folder or a user folder, check how sharing behaves for guests and external users, and set retention in line with your records policy. Then test sharing with at least one account from each role on the permissions map. Output: a sharing and storage note with a test log showing that each role can do what the map allows and nothing more.
Import or create starter data
The pilot lead builds a starter board from the specification and seeds it with a small set of current items. If work is moving from spreadsheets or another board tool, map each source column to a table field first, and test the import on a copy before it touches the pilot board. Confirm which import method your release supports. Output: a board template the team can reuse, plus a data-mapping sheet that records each source column and its target field.
Run the pilot on live work
The pilot team tracks its live work in Deck and Tables for the period set in the charter. The pilot lead logs every friction point as it appears, such as a missing field, an unclear status, notifications that arrive too late or too often, or an attachment that fails to upload. The lead reviews the log with the sponsor at regular check-ins. Output: a pilot log with dated entries, usage notes and a list of requested changes, each tagged with an owner.
Hold the pilot exit review
The sponsor, the platform owner and the pilot lead review the log against the charter. For each work type, they decide whether it stays in Deck and Tables, moves to the dedicated project tool or waits for a fix. They also update naming, label, status and due-date conventions to match what the team actually used. Output: a pilot exit review record with the decisions, the revised conventions and the changes that feed into the board template.
Roll out with onboarding guide and owners
Publish the updated board template and a short onboarding guide covering how to create cards, attach files, use labels and find the board owner. Assign one named owner to each board. That owner approves membership changes, runs the review cadence and keeps the conventions current. Confirm the support route for questions and permission problems before users arrive. Output: a rollout checklist showing each board, its owner, its members and the date the guide was published.
What drives the effort of a Deck and Tables rollout
This table lists the factors that raise or lower the effort of a Deck and Tables rollout, how each one changes the work, and what keeps it contained. Read it before asking a partner for a scope, because each driver maps to a line item a written quote should break out. The main takeaway is that most effort comes from decisions about teams, permissions and conventions, not from installing the apps.
| Driver | How it changes the work | What keeps it down |
|---|---|---|
| Number of teams and boards | Each team needs its own boards or tables, owners, labels and stages, so setup and review time grows with every team added at once. | Start with one pilot team, then add teams in waves once the first board runs without changes for a few weeks. |
| Depth of the permission model | Deck boards and Tables are shared with users, groups and circles, and guest or external shares add checks on who sees which card, row or attachment. Deeper rules mean more test cases. | Use the fewest sharing levels that match real roles, and document one owner per board or table. |
| Volume of data to migrate | Moving existing task lists from spreadsheets, another kanban tool or a project tracker means mapping fields, cleaning rows and checking attachments that link to files in Nextcloud. | Migrate only open items and recent history, and keep archived projects in their original location with a read-only reference. |
| Integrations with other tools | Connections to a ticketing system, chat, calendar or identity provider each need configuration, credentials, error handling and an owner who maintains them after go-live. | Begin without integrations, and add one only when a named process cannot run without it. |
| Workflow conventions to agree | Stage names, card fields, labels, due-date rules and table column types need agreement across teams. Every unresolved convention becomes a rework request later. | Agree a short, fixed convention set before build, and record it in one page that all team owners sign off. |
| Guest access requirements | Guests who need to view or edit a board or table add invitation rules, expiry decisions and file attachment checks, and they often raise questions about what data may leave the organization. | Decide in advance which boards may be shared externally, and keep external access to a separate board. |
| Training needs | Users who already work in spreadsheets or another tool need time to learn card and table conventions, and support requests rise in the first weeks after launch. | Provide a one-page guide per team and a named internal champion who answers first-line questions. |
| Internal staff time (one-time) | Your team spends time on decisions, testing, migration checks and sign-off. This cost is paid in staff hours and is incurred during rollout. | Ask the partner to state which decisions and reviews need your staff, and schedule those reviews in advance. |
| Partner scoping and delivery (one-time) and ongoing ownership (recurring) | A partner's fixed-scope work covers scoping, configuration and handover, which is one-time. Someone must still own board structure, user changes and app updates, which recurs after launch. | Ask for a written scope that separates build and handover from any ongoing support or retainer, and name the internal owner for upkeep. |
Where a dedicated project tool still fits better
Deck and Tables suit team tracking, but they are the wrong primary tool when planning itself is the work. Multi-level portfolio planning, dependency and critical path management, resource and capacity planning, time tracking tied to billing, detailed reporting across many projects, and heavy automation against external systems all push beyond what a kanban board and a table app are designed to hold. If one of these is central to how your organization runs projects, the decision is not whether Deck can be stretched to cover it, but where the planning record should live.
Many teams settle on a split. Files, meeting notes, attachments, lightweight task lists and approvals stay in Nextcloud, where sharing and permissions already follow the rest of the platform. Formal planning, schedules, capacity models and time records sit in a dedicated project tool such as OpenProject or Plane, which your planners already know how to use. The two are linked through links to work packages, cards that point to an external item, or an integration built on the Nextcloud app store and documented server features. The link itself needs an owner, a naming convention and a rule for which system is authoritative when the two disagree.
Before deciding, take your top three reporting and workflow requirements and test each one against the app in a staging instance with realistic data. Choose requirements that are hard to do without, such as a monthly cross-project status view or a dependency that must block a handoff. Record what the app does, what it does only with workarounds, and what it cannot do. Then check every gap against the current Nextcloud documentation for Deck and Tables and the apps you plan to connect, and confirm the behavior with the vendor or in your own environment instead of assuming a feature exists or is absent.
Plan for the cost of the split as well as the cost of the tool. Someone must maintain the integration, handle its upgrades alongside Nextcloud major releases, and keep identity, permissions and retention aligned between the two systems. Ask any implementation partner to quote this integration and its ongoing support as a separate line from the platform work, and to state which records each system holds, who can change them and how a departing user's items are handled in both places.
How Deck and Tables connect to the rest of the platform
Deck and Tables sit inside Nextcloud, so their access, sharing, file storage and alerts follow the same identity and file settings as the rest of the platform. The cards below cover each connection, the decision to make before configuring it, and the checks to run in the installed app version.
Directory groups and board access
Board access depends on Nextcloud users and groups, so the LDAP or Active Directory app must sync the accounts and groups your teams use before boards are shared. Decide first which directory group maps to which board or team, and whether that group should be an owner or a member. The LDAP app lets directory users log in with their own credentials, so an assignment resolves to the Nextcloud user ID created from the directory account. An attribute or username mismatch can leave a card assigned to an account that cannot sign in. Confirm the user ID attribute and group filter in your installed version.
OpenID Connect and SAML sign-in
Nextcloud documents OpenID Connect and SAML authentication backends, which move sign-in to an external identity provider while Nextcloud keeps the user record. Decide which system is the source of truth for users, and how group claims or attributes are passed to Nextcloud. Group changes may only reach Nextcloud at the next sign-in, so a board access change made in the provider can lag until that user logs in again. Confirm the backend app, its claim settings and the supported provider versions in the installed Nextcloud release before planning the mapping.
Team Folders and file attachments
Files attached to a card are stored in Nextcloud, so their access follows the location where they are saved. Decide whether attachments go into a Team Folder that carries the team's permissions, or into a folder controlled by one person. Moving or unsharing a file outside the board can break the attachment link for members who relied on it. Check how the installed version handles attachments in Team Folders, along with quota and trash retention settings, before the first board is rolled out.
Talk discussion around a card
Teams often discuss a card in Nextcloud Talk, either in a conversation for the whole team or in a conversation linked to the work item. Decide whether one conversation per board, per team or per card fits your volume, because per-card conversations multiply quickly and are harder to find later. Talk participants can only see files and card details that their permissions allow, so test with a guest and a directory user. Confirm the Deck and Talk integration options in the installed versions, and check which Talk backend your deployment uses.
Assignment notifications and activity
Deck can alert users when a card is assigned to them or when it changes, and these alerts appear in the Nextcloud notification system and, where enabled, by email. Decide who should receive assignment alerts and whether due-date reminders are needed, since each user's notification settings decide what they receive. Test with a standard directory account rather than an administrator account, because administrators often have different defaults. Confirm which events the installed Deck version emits and how the server's email delivery is configured.
Links to project and chat tools
Deck cards and Tables rows are not synced with external project tools or chat systems by default, so any two-way link needs an integration that your team or a partner builds and operates. Decide the system of record for each item, which fields sync, and who resolves conflicts when both systems change. If the work is mainly planning, a dedicated tool such as Plane, OpenProject or Redmine may hold the backlog while Deck handles daily tasks. Confirm the available APIs and webhooks in both systems before scoping the integration.
Questions teams ask before implementing Deck and Tables
How much does a Nextcloud Deck and Tables implementation cost?
DeployOpen does not publish a price list, so the cost follows from a written scope. Three cost groups matter. Software: the Nextcloud server is open source under AGPL-3.0, so the community edition carries no license fee. If you choose Nextcloud Enterprise, the pricing page lists Standard from 71.29 euros per user per year for 100 or more users, with a 100-user minimum. Implementation work: planning, convention design, configuration, testing and training, quoted from the agreed scope. Your staff time: owners, decisions, data review and testing. Recurring costs include hosting, maintenance and upgrade testing, while the build is usually one-time. Ask each quote to show line items, stated assumptions and which costs are one-time and which recur monthly or annually.
How long does a Deck and Tables pilot take to complete?
No fixed duration applies to every team, so the timeline is set in the written scope. The main drivers are how many boards and tables the pilot covers, whether groups and sign-in come from an existing directory, how much data must move from a current tracker, how many people join, and how quickly owners make convention decisions. A pilot with one team and a small set of boards moves faster than a rollout across several departments that need approvals. Ask the proposal to list each phase, the deliverable it produces, the decisions that must be made before the build, who signs off each phase, and how the pilot moves into production.
What must our internal team provide before a pilot starts?
Four inputs decide whether the pilot starts on schedule. Owners: a named business owner for each board or table who can accept or reject changes. Convention decisions: board naming, stage names, labels, table columns and column types, who may create boards, and how archiving works. Data: sample tasks or exports from the current tracker, so the team can test migration and layout, plus the sharing model for each group. A pilot group: a small set of users from one team who will use the boards for live work and give feedback. You also need an administrator who can manage groups, sharing and app installs on a test server, and an identity owner if sign-in comes from a central directory.
Can our team set up Deck and Tables without an implementation partner?
Often yes for a small team with a clear use case, because both Deck and Tables are Nextcloud apps that an administrator can install and configure. The harder work is governance: agreeing conventions, sharing rules and retention, and keeping the apps working through upgrades. Check whether you have an administrator with time for the pilot, someone who owns board design, and a staging server where each Nextcloud upgrade can be tested before production. Confirm that the app versions you plan to use support your target Nextcloud version. A partner adds the most value when the scope spans several departments, must connect to identity and other tools, or needs documented evidence for an audit.
When is a dedicated project tool better than Deck and Tables?
Choose a dedicated project tool when the work needs task dependencies, timelines, resource planning, time tracking, detailed reporting or a portfolio of many projects. Deck and Tables suit lightweight tracking beside the files, comments and attachments your teams already keep in Nextcloud, such as intake queues, content calendars and small operational trackers. To decide, walk one live workflow through each tool and list the fields, views and reports the team needs in the first phase. If the answer is a separate tool, DeployOpen also implements dedicated work-tracking platforms, including OpenProject and Plane, inside infrastructure you control.
How does Nextcloud release timing affect Deck and Tables planning?
Nextcloud publishes a new major version every four months, and each major version receives one year of support through monthly maintenance releases. Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 with end of life in September 2027. Nextcloud 34 is supported until June 2027, and Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. Plan app changes around this cadence. Schedule each upgrade, confirm Deck and Tables compatibility for the target version, and upgrade one major version at a time with a backup before each step and checks on third-party apps. Nextcloud does not allow skipping major releases during upgrades.
Do Deck and Tables data and settings survive a Nextcloud upgrade?
Upgrades can change how apps behave, so test on a staging copy of the server before each production upgrade. Follow the Nextcloud rule: upgrade one major version at a time, back up before every upgrade, and disable third-party apps until each is confirmed compatible with the new version. Deck and Tables are Nextcloud apps, so their compatibility belongs in the same upgrade checklist as every other app you install. Check the system requirements for the target version too, since supported database, PHP and web server versions change between releases. Ask any implementation partner for a written upgrade procedure, the test scope and the rollback steps.
How DeployOpen works on this
DeployOpen plans and deploys Nextcloud Deck and Tables inside the same Nextcloud instance that holds your files, so team tracking uses the sharing model, file attachments and comments your teams already use. Work starts with a written scope that states which boards, tables, groups and integrations are covered. We then build, test and document the setup in infrastructure you control, and support is available as a retainer.
How we scope
- Written scope listing which Deck boards, Tables and team groups are in the engagement
- Decision on which work stays in Deck and Tables and which moves to a dedicated project tool
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Sharing model, group membership and file attachment paths configured to match your existing Nextcloud permissions
- Test cases for board permissions, comment visibility, attachment access and guest sharing before users see the setup
- Integration and app choices reviewed against the Nextcloud version in use and third-party app compatibility
How we hand over
- Documentation of board and table structure, sharing rules, and the naming conventions your teams agreed
- Admin runbook covering app updates, backups before upgrades and disabling third-party apps during upgrades
- Walkthrough sessions for team leads and administrators, with a record of what was delivered
How we support
- Retainer options for maintenance, upgrades and continuous testing after the initial delivery
- Planned upgrades move one major Nextcloud version at a time, with a backup taken before each step
- Ask the partner to confirm how support hours and response times are defined in the written scope
