Planning Studio

In New appointment, search for a customer directly or select Or choose a customer. The form does not reload. Changing the customer loads their contacts and addresses while preserving the title, times and internal note. Choose a result or clear the search text for an appointment without a customer. A previous customer’s contact or address never carries over to another customer. If the appointment is somewhere other than the customer's saved addresses, fill in Other address (street, number, postcode, town). It takes precedence: it shows in the agenda, the message and the route link, and the route looks up the place itself. Clear the field and the saved address applies again. It also works without a customer.

Time fields have a clock button with the shared date and time picker. Typing still works. Cancel changes nothing; the selected time must satisfy the allowed limits. The email preview uses the existing email template and sends nothing. Calendar and route cards show customer, address and contact where space permits; details contain the full information.

A shared route link remains visible for manual selection. If direct copying is unavailable, the button tries a local selection fallback. If both fail, the text remains available to copy manually and no success message appears.

With Planning Studio you record who does what and when. You work with projects, each with its own board, and with a calendar for appointments. Everything belongs to a client, or is Internal: your own work without a client.

You find the studio under Planning Studio in the left bar. The module is switched on or off per workspace. Someone who may only look along (the reader role) sees everything and changes nothing. A client who is a guest in the workspace does not see Planning.

The field staff role is for a technician or another employee who works outside. They only see their own route and jobs (under On the road) and nothing of the board, the calendar or colleagues' jobs. They submit their working days, hours and absence themselves as a proposal; a planner approves or rejects it, and only then does it count in the occupancy. Absence has no reason: that is health data and we do not record it. The screens to submit and approve will follow; the role and the rules are already in place.

Projects and boards

A project has a name, a key (such as KAL) and belongs to a client or is Internal. A board has columns, by default To do, Doing, Review and Done. Every item carries the key of its project, for example KAL-12.

A compact card shows the type (task, story or bug, with an icon and a name), the key, the title on two lines, at most two labels and then a count, the points, the risk, the deadline (when it has passed it is red and says overdue), who does it (a person with a photo, the crew or an empty dashed outline) and counters for criteria, comments and branches or pull requests. A colour bar on the left belongs to the epic.
A column shows its count, its points and a soft limit: over the limit the counter changes colour and a sentence says so, but nothing is refused. A column with many cards shows eighty first and lets you load more.
Moving an item works four ways: dragging with the mouse, the handle on a phone, the keyboard (Space picks the card up, the arrows choose a column and a position, Space puts it down, Escape puts it back; Alt with an arrow moves it in one go) and the menu on the card, Move to. Every move is read aloud. The card sits in its new place at once; if the server says no, it goes back and says why.
Searching and filtering is above the board: search by title, key or label, Only my items, a filter per owner (the faces), per label, per epic and Overdue. With a filter on, the screen says how many of the total you see, and one click clears them.
Grouping by owner or epic puts the board in lanes with a collapsible heading. You can drag within a lane; moving a card to another lane is done in the drawer, by changing the owner or epic.
The sprint header above the board of a project with sprints shows the running sprint: goal, dates, points done of the total, the working days left and a small burndown. On the sprint you switch between Chart, Burnup, Flow and a table: Flow stacks per day how many points were in each column of the board (what is done at the bottom). The diagram builds up from the day this feature exists; a day without a recorded state is not in it and is never drawn as zero. The board then shows only the items of that sprint; with Whole board you see everything.
Quickly creating an item is possible at the bottom of every column with + Item: type a title and press Enter, the field stays open for the next one.
The whole item opens on the right in a drawer, without leaving the board. The address gets ?item=KAL-12, so sharing works and the back button closes the drawer. See An item in detail.
A column with the status category Done closes the item.
A status category per column: To do (grey), In progress (blue), Review (orange) or Done (green), as in Jira. The category sets the colour of the status on the card, in the drawer, on the item page and in the backlog, and whether an item in that column counts as done. Colour is never the only sign: the column header has its own icon per category and every status names itself.
Managing columns from the board (an administrator): Column adds a column (name, status category, WIP limit) before the column that closes work. The menu next to the column name edits the column, moves it one place left or right, and deletes it. Order columns lets you drag the order (or use the arrows, or Alt with an arrow) and save it. Deleting a column that has items first asks which column they move to; an item never disappears, and a board keeps at least one column. Moving into or out of a column that closes work marks the item done or open again, and the trail names every moved item. A board has at most 50 columns.
A board template you pick when you create a project or team: Scrum (To do, In progress, Review, Done), Kanban (with a Backlog added) or Simple (To do and Done). You adjust the columns on the board afterwards.
The tab bar of a project with sprints (Backlog, Sprints, Plan ahead, Team, Standup, Reports, Release notes, Automations and Board) works at every width: if it does not fit, it scrolls sideways with fading edges, the tab of the page you are on stays in view, and More opens all tabs in a menu. Arrow left and right, Home and End walk along the tabs.
An administrator makes projects, adjusts columns and limits and archives a project.

An item in detail

An item opens as a window over the board by default, with previous and next (also with the J and K keys, except while you type in a field), a fixed footer with Delete and Mark as done, full screen, and the whole screen on a phone. If you want the board next to the item, choose Open as a side drawer; that choice is per user. An item also has a page of its own (Open on the full page). Window, drawer and page show the same parts. Mark as done puts the item in the first column that closes work; with open criteria the screen asks for confirmation first.

Title and description are edited with a click; Enter or clicking away saves, Escape puts it back.
Details in groups with an icon per field: Who (customer, owner, the crew, the contact for the customer and buddies), How urgent (status, priority, risk and points), When (sprint and deadline), and below them epic, type, labels and watchers. Every change appears on screen at once and is saved. Only a person with the right on the crew sets the risk; anyone else only sees it. An item with the crew is only taken back by such a person.
Priority is low, normal (the default), high or urgent. It is an opinion about urgency and separate from risk: a higher priority never gives an agent permission. On the card and in the backlog list a small flag mark with the word shows (Low, High or Urgent; Regular is the default and stays empty), in a narrow list just the flag, with the word on hover. In the backlog the High and urgent chip shows only open items with priority high or urgent, with the count on it; together with other filters it means and. A different priority also counts as a change for watchers.
Add to calendar sits under the deadline (only when there is a deadline and you may plan). The button opens the New appointment form of the calendar on the day of the deadline, with this item already chosen; you pick the person and time and save it yourself. Nothing is created until you save, and the message to a customer is still signed by a person.
Contact for the customer is a person from Relations who belongs to the project's customer, not free text. You can only pick one if you may read Relations; a project without a customer has no contact.
Buddies are colleagues who work on the item (a member of the workspace, at most 20). Unlike a watcher, a buddy works on it.
Let the crew do this gives the item to an agent (with the right on the crew), also from the window and the drawer. The risk stays with a person.
Points you pick from a list: 1, 2, 3, 5, 8, 13 or 21 (or no estimate). Above 8 the screen asks you to split the item. You pick them in the drawer and in the backlog too.
Acceptance criteria sit right under the description, at the top of the item. You tick them off in a list, with a count and a bar. Moving an item with open criteria to Done asks for confirmation first.
Subtasks: you split an item into small steps. A subtask is an item of its own with its own key (KAL-31), status and owner; you create it inline in the drawer, tick it off (it moves to the first column that closes work; if it still has open criteria the screen asks for confirmation first, as on the board) and open it in the drawer, where the parent item is shown above the title. Progress counts the finished subtasks, and the card on the board shows 2/5. A subtask does not appear on the board or in the backlog itself and does not go into a sprint on its own: it goes along with its parent. A subtask has no subtasks of its own (one level deep) and an item has at most 50. If you delete the parent, the subtask stays as an ordinary item.
Watchers: who follows an item without owning it. You put yourself on Watch this item or add a colleague; every watcher is a user of the workspace, shown with their avatar. At most 50 per item. A watcher gets a notification in the bell (type An item you watch was updated) when the item is changed, commented on or moved to another column, with the item key and title but without the text of the comment. Not when you did it yourself, not when you are no longer a member, and never by email or push. When an item changes often the notifications add up into one per ten minutes. To opt out, switch the type off under Notifications.
Avatars show a photo or the initials on a fixed colour taken from the name (without a name, the username), on the board, in the backlog, the drawer and the filters.
Activity has the tabs Conversation, History and Work. The Conversation shows comments with cards for what happened in the code (approved, changes requested, merged, commits), in time order; the History lists everything per day. A card only appears when the GitHub data knows it: who did it and "put on test" are not there yet. Relations link two items of your workspace, also across projects: blocks, belongs to or duplicate of (the other side shows the opposite word). A blocker that is not done yet warns when you complete an item but never stops you. You post comments with Ctrl+Enter or the button; the crew also leaves them through the MCP. The History says who did what (moved, set points, chose an epic) without ever copying the text of a title or description. Work shows hours and the branches and pull requests of the item.
Changing at the same time: if someone else works on the same item at the same time, your change does not overwrite what they just did. You get a message and with Reload you see the current state.
Copy link and Delete (with a confirmation; only an administrator, and an item with hours or an invoice proposal stays) are in the drawer. On a phone the drawer fills the screen and the details are at the top.
On its own page, the work of the crew, the branches and pull requests (with propose merge) and the appointments are also on the right under the details.
Who is here: when someone else from your workspace is on the same item or the same board, you see their face at the top right. Hover for the name and whether they are viewing or editing. A face is dimmed with an empty ring when someone does nothing for 90 seconds, and disappears when their tab closes or they send no signal for 30 seconds. A member of your agency shows with the small bar and the word Agency, and a platform admin who deliberately looks along is shown as long as the page is open, as a shield with the label Platform, the state and the reason, without a name or photo; the bar at the top remains the place where you always see this. You cannot turn this off. Nothing is stored: no history, only who is here right now. You only see people who may see the same page.

Attachments on an item

You can keep files with an item: a screenshot of a bug, a PDF briefing, a CSV with figures. They are in the Attachments tab of the drawer and of the item's page.

Adding: pick files, drag them onto the box, or paste an image from your clipboard (Ctrl+V or Cmd+V). Each file gets its own line with progress; a file that is not allowed is shown with the reason and the rest carries on.
What is allowed: png, jpeg, webp and gif, pdf, text files and csv. The type follows from what is inside the file and not from its name: a file that pretends to be something else (an html page named .png) is refused. Svg, html, scripts, programs, zip and office files are not accepted.
How many: at most 25 attachments per item, 10 MB per attachment, 100 MB per item and 512 MB per workspace. If you hit a limit, the screen says which one, and you remove an attachment first. Attachments are kept in the same storage as your other files (images in secure storage in the EU) and count towards the storage space of your plan: if it is full, a new attachment is not accepted. The same file on several items takes up space only once.
Safe: an image is rebuilt when it is added. A location or camera details in a photo (exif) do not come along, and images are at most 5120 pixels on the longest side. A pdf is checked in a sealed environment, and a pdf with a script, a launch action or an embedded file is not stored. If the check cannot run, a pdf is not stored. A file name is cleaned up.
A csv or text file stays as it is. We change nothing in it. A spreadsheet program can run a cell that starts with an equals sign as a formula, so open a csv from someone else with care.
Viewing: an image opens in a large window where you page with the arrow keys (Escape closes). Everything else downloads, and every attachment has a button to download and to copy its link. A link only works for someone who may work with Planning in the workspace: there is no public link.
Deleting asks for confirmation and really removes the file (from storage too, once no other item has the same file). Attachments are part of your workspace export, in the bijlagen/ folder. Deleting an item also removes its attachments. Anyone who may plan can add and delete; anyone who can see the item can read.
In a trial (without authorisation) you see images with a watermark and in low resolution and you cannot download pdfs, text or csv; that comes with the authorisation.

Description with formatting

An item's description has a real editor. Click Edit the description and you get a toolbar with headings (large and small), bold, italic, strikethrough, code, bulleted and numbered lists, a task list you can tick off, a quote, a code block, a divider, a link and (once attachments exist) an image, plus undo and redo.

Keyboard: Ctrl+B, Ctrl+I, Ctrl+K for a link, Tab and Shift+Tab to indent or outdent a list item, and type ## , - , 1. , [ ] or > at the start of a line for a heading, list, task or quote. Ctrl+Enter saves, Escape cancels, and Alt+F10 jumps to the toolbar (the arrow keys move through its buttons). On a phone the toolbar scrolls sideways.
Links may point to https: and mailto:; any other address is refused. Images only come from Planning's attachments, never from another site.
What you save is plain text (Markdown): agents and the MCP read it as it stands, and an old description without formatting stays exactly as it was. Text outside the formatting, such as HTML, is shown as text and never run; invisible characters are removed. A description is at most 20,000 characters.
Someone who may only read an item sees the same formatting without the editor loading.

The client card

For a client you see, in a simple form, who it is, how to reach them, which projects and work are attached, the upcoming appointments and the latest events. From the card you make a job (it goes in that client's Jobs project, which is made if needed) or a new project. The card is part of the core of every workspace: you do not need the Relations product for it. That adds deals, follow-up and the client portal.

The calendar

The calendar is a drag board with three views: day, week and month. In the week every person has a lane with the appointments per day. A person is a colleague with an account or someone without an account, such as a technician: they only have a name.

An appointment has a title, a start and an end, who does it, and optionally a client, a contact person, an address and an item. The times are read in the workspace's time zone.
A double booking warns and does not block. Two appointments of one person at the same moment get a notice and the label Double booked. Back to back is not an overlap.
Dragging to another day, another person or (in the day view) another time moves an appointment. The keyboard works too: Alt with the arrow keys moves an appointment a day or to the next person, in the day view a quarter of an hour. On a phone you open the appointment and choose Move. Undo works with the button above the board, in the notice after moving, or with Ctrl+Z.
The workload per person per day is at the top of each cell: how many hours someone is busy that day against their hours a day, for example 2h45 of 8h. Appointments in Denkploeg and busy time in their Google calendar count together, overlap once. Above 85 percent the day is full, above 100 percent overbooked. If someone has no connected Google calendar or no hours a day, or reading fails, it says unknown and never free. If someone is absent that day (an administrator sets that under Team of a project with sprints), it says absent, not free, and without a reason. An administrator sets the hours a day under People and calendar links; new people start with 8 hours.
Connecting Google Calendar is possible at the top of the calendar, in the Google Calendar block. It says whether Google Calendar is connected, whether the permission has expired or permissions are missing, and has the Connect Google Calendar button (or Reconnect) for those who manage keys and connections; others see the status and a line saying an administrator has to do it. Denkploeg only reads whether someone is free or busy, never why, and only puts an appointment in Google after the planner confirms it. After connecting you land back on the calendar. You withdraw the permission under Connections. If a permission already exists, reconnecting asks for the code from your authenticator app.
Signals above the board: how many appointments are double booked, how many days are overbooked, and whose calendar is not connected. A double booked appointment has a red border. The board warns and does not block.
Still to schedule shows open jobs without an appointment. With Schedule you turn one into an appointment, with the job and the client already filled in.
Reading busy time from Google: for a person you can set a Google calendar address. We then only read when that calendar is busy, never why, and only to warn. Without a connection to Google there is a test calendar and the screen says so. If a calendar cannot be read, it does not say free but: we could not read it.

Recurring appointments and time windows

For a new appointment you choose under Repeat: every week, every 2 weeks, every month or every quarter. For a week you choose the days; you set an end (after a number of times, on a date, or never). One sentence sums up the rule, for example Every other week on Tuesday, 8 times, with the upcoming dates below it.

Twelve weeks ahead. A series without an end is always twelve weeks ahead in the calendar and is topped up every week. You can stop it at any time; the upcoming appointments are then cancelled without a message to the client.
A monthly appointment on the 31st falls on the last day in a short month, and the form says so.
Public holidays (in a workspace in the Dutch time zone): an appointment on a public holiday does not go ahead by itself. At the appointment you choose to skip it or move it to the next working day; until then it is not in the calendar and no message goes out.
If you move an appointment from a series, the board asks: only this one, or this one and all following. All following move by the same amount and go to the same person. An appointment you moved or cancelled separately stays that way when the series is topped up.
Limits: at most three running series per contact person and two hundred per workspace, and a client gets at most six messages a day, even if more series fall on the same day.
If someone else changed the appointment in the meantime, moving or undoing changes nothing and the screen asks you to refresh.

Under When do you come you choose an exact time or a time window, such as between 9 and 12. In the message to the client a window always appears as between 09:00 and 12:00, never as an exact time. The form warns about a window shorter than an hour or longer than five hours, and the start of the appointment always falls within the window. The form shows exactly the email the client gets.

Calendar on your phone

Every person can make a calendar link. That is an address you add as a subscription in Apple Calendar, Google or Outlook. The calendar refreshes by itself: Apple about every quarter of an hour, Google can take up to half a day.

The address is shown once. Save it straight away.
Anyone with the address sees that person's appointments. Do not share it. A new link replaces the previous one, and revoking works at once.
The calendar only holds the title, time, place and the key of the item. No client details and no notes.

Messages to the client

If you choose a contact person of the client with an email address for an appointment, a confirmation and a reminder a day before are prepared.

Everything that goes to a client runs through the crew's gate: every message is an action at risk level 1. As long as the workspace does not let the Planning channel run by itself, every message waits under To sign for a signature. Switch the channel on (Automation, level 1 or higher) and they go by themselves.
The title of the appointment is in the message, the internal note never is. A time window appears as between and; for a series the rule is in the confirmation.
For a recurring appointment the client gets one confirmation, at the first appointment, and a reminder for every appointment. If you move one appointment, or this one and all following, they get a new confirmation.
If the contact person has switched email off, has no email address, or there is no contact person, nothing is sent and the reason is shown with the appointment.
If you move the appointment, a message that was still waiting for the old time lapses and a new confirmation follows. An appointment less than a day away gets no reminder.
Cancelling sends the client nothing. You cancel with a client yourself.

Handing work to the crew

An item can be with a person or with an agent of the crew. The rules are fixed:

The risk comes from a person. Only someone with the right on the crew (an owner or administrator) sets the risk of an item and gives it to an agent. Text in the title or description never changes that: an item cannot give itself a low risk.
No risk means: do not pick it up. An item without a risk counts as R3, and R3 is always done by a person.
An agent does not work on the item itself. The item becomes a work item with source planning and the agent works there. If you change the title, the description or the risk, the version goes up and an agent still working against the old version does not deliver.
Assigning a person takes the item back from the crew. You can also take it back yourself.

Code and GitHub

You can link one or more repos of your workspace to a project (Code on the board). A branch or pull request that carries the key of an item then shows up on that item: the branch, the pull request with its status, the checks and the review.

The key finds the item. A branch named feature/KAL-12-short-title (or fix/ or chore/), or a pull request with KAL-12 in its title, is attached to that item. A key in the text of a pull request is a reference only. Without a key nothing is attached: we never guess.
Only your own repos. You can only link repos from the GitHub organisations connected to your workspace. A key of another project or workspace does nothing.
Status rules. Per project you choose, on or off, what an event does: a branch made, a pull request opened (for example to Review), changes requested or a pull request merged (for example to Done). A rule only moves an item forward and never undoes what a person moved.
Create branch. On the item. It makes a branch with the item key in its name from the base branch of the repo. It goes through the crew's gate like everything that leaves the platform: until the workspace lets the GitHub channel run by itself, it waits under To sign. An existing name is an error and is never overwritten.
Branches create items. Per connected repo, off by default. When it is on, a new branch without the key of an existing item becomes an item in the backlog of that project, marked From a branch, with risk R3 and no owner. Main, master, develop, the base branch, release/ and dependabot/ do not count, the same branch never makes a second item, a deleted branch leaves the item in place, and no more than 20 per hour per project are created. The backlog tells you which ones still need an estimate or owner.
Text from GitHub is data. A title, branch name or commit message can link an item, and at most move it a column forward by your own rule. It never sets a risk, never gives an agent an instruction and never changes a rule. Pull requests from a fork do not count.

Setting up the webhook on the GitHub side is a task for the platform owner.

Comments and your own client

Comments on an item. On an item's page you add a comment: what you did, what you found or what you are waiting for. A comment stays as it was written and only disappears with the item. A comment from the crew carries the label Crew.
Working from Claude, Codex or Cursor. With a key from Connections, Denkploeg in Claude you read your boards and tasks from your own client, create a task, update it (title, description, labels, deadline, type, column) and add a comment. A task on your own board does not go out, so it needs no signature; every change is in the History. A person sets the risk and who picks a task up. Only a person moves a task with open criteria to done, in the screen.

Automations

Under Automations (inside a project, via the address bar or the tab) you make rules shaped like When this happens, the rule does this. You choose from lists, without programming anything.

When. An item moves to a column, is created or assigned, gets a label, the deadline gets near (you choose how many days) or has passed, a branch was created, a pull request was opened, merged or closed without merging, a review was requested, changes were requested or the pull request was approved, the checks passed or failed, all subtasks of an item are done, or a sprint started or was completed. A review only counts from someone with write access to the repo; a bot does not count.
Then. Move the item to a column, assign it to a person, its creator or an agent of the crew, add a label, set points, create a subtask (as soon as subtasks exist), add a comment to the item, send a notification or create a new item. In the screen a rule has one or two actions.
Only for. A rule can be limited to a work type (task, story or bug), an epic, a label or an owner (a person or an agent). If more fields are filled in, an item must match all of them; an empty field means all items. If the epic a rule refers to disappears, the rule stops firing and the rule says so. A sprint has no item, so no condition fits there.
Counter. Every rule shows how often it was applied and when it last was. The counter covers what the log still keeps (90 days).
On and off. Every rule has a toggle. A rule that is off does nothing.
Templates. Four common rules are ready in one click: a branch moves the item to In progress, an opened pull request to Review, a merged pull request to Done, and a passed deadline adds the label te-laat and notifies the assignee.
Log. Under the rules are the last 50 times a rule fired, with the outcome (done, skipped, limited or failed) and the reason. No titles or texts of items are in it. The log keeps 90 days.

A message in Discord or Slack. Under Chat channels you connect a webhook from Discord (Server Settings, Integrations, Webhooks) or Slack (an app with Incoming Webhooks) with a code from your authenticator app. You can connect more than one, one per purpose: for example Deploys, Sprint and Errors. The webhook is stored encrypted in the vault and never comes back, not even for you. A rule with the action Post a message in a chat channel then picks the channel the message goes to; so a sprint that starts goes to the sprint channel and a failing check to the errors channel. The message has a fixed form (the key and title of the item and the name of the rule, or just the name of the rule when there is no item, as with a sprint), pings nobody and has no links. At most ten messages per minute go to a channel; if Discord or Slack answers with an error because the webhook is gone, the channel turns itself off and the screen says so. A proposal from the director cannot send a chat message: a person chooses that. A trial workspace sends nothing outside. Notifications about a deploy or an error outside Planning Studio come later: they need a source of their own.

What a rule never does:

A rule does not set a risk level and sends nothing outside except a fixed message in a chat channel that a person connected: no email and no free text. A notification goes to someone in your own workspace.
Through a rule an item only goes to an agent within the rules that apply to that agent (how many at a time, the highest risk, excluded labels). Only a person with the right to direct the crew chooses that, and that right is checked again every time the rule fires. Without a risk level set by a person the agent does not pick the item up.
A rule that moves an item to Done leaves an item with open criteria where it is and writes why in the log. A person then moves it to done.
A rule uses fixed fields. Text from a pull request, a branch or a comment never becomes a label, a title or any other value of an action.
A rule does not fire on what another rule did. A rule that fires too often also stops (three times a minute on the same item, thirty times a minute, or a hundred rules a minute in the whole workspace): the log says limited and the administrators get a notification.

Making, changing, switching on and off and deleting rules is for someone with the right to manage Planning. Via MCP you can read the rules (planning_automations_lezen), switch an existing rule on or off (planning_automation_aan_uit) and put a rule forward as a proposal (planning_automation_voorstellen). A proposal is off and does nothing: someone with the right to manage Planning reads it on the Automations page and reads per action what the proposal does, including the text of a comment, notification or new item, and confirms Take over and switch on (a rule that gives an item to an agent also needs the right to direct the crew). A proposal can never give an item to a person or an agent and is never switched on by itself; a project holds at most ten proposals at a time. Changing or deleting a rule is only done by a person in the screen.

Test report

An item with a test plan has a Test report (pdf) button in the Test plan block. The report has a cover with the client's logo and name, a summary ("x of y succeeded" with the number of succeeded, failed and open steps) and a table with every step, what you expected, the result, who set it and, for a failed step, the note. It is always in the house style of the item's client (colours, fonts and logo from that client's brand profile), never Denkploeg's; for an internal project it uses your own workspace's house style. If the client has no brand profile with colours, fonts and a vector logo yet, Denkploeg makes no report and says why. A result is shown as a word and a shape as well as a colour. Only people who may plan can make it. The test plan stays internal: a client does not see it, and the report only comes to you as a download. Sending it to the client is something you do yourself, outside Planning Studio. A trial workspace does not make reports. Through MCP, planning_testrapport_lezen reads the same content as JSON, without the pdf.

What comes later

Merging and releasing from the board, the crew as a team member with rules and limits, sprints and client view in the client portal are planned and not in yet.

Connecting Google Calendar

Connect Google Calendar under Connections and enter the person's calendar address. The Google account must have access to that calendar. Planning reads busy blocks only. An administrator can choose Propose for Google Calendar on a planned appointment. The planner then confirms under To sign, including the required extra code. The proposal shows the title, times and calendar. Changes require a new proposal.

This first version only creates events, without attendees or invitation emails. Changes and deletions are not synchronised yet. Push notifications signal changes; availability is read again through freeBusy. The portal must be reachable over HTTPS. Failed channel registrations are retried by the worker. Disconnecting removes local access and revokes Google consent.

Add to your calendar opens a menu for Apple Calendar or Outlook through an .ics file, Google Calendar, Outlook.com and Outlook with a work or school account. Opening the menu does not add anything to an external calendar.

Via MCP and the director

The director and your own programs (Claude Code, Codex) reach Planning through the MCP, with a key for your workspace. For the calendar and projects that means:

Appointments: planning_afspraken_lezen, planning_afspraak_maken, planning_afspraak_wijzigen, planning_afspraak_annuleren and planning_afspraak_afronden (right planning.plannen). Creating or moving an appointment follows the same conflict check as the calendar: warn, never block. Recurring appointments stay in the screen.
Customer card and jobs: planning_klant_lezen and planning_klus_maken. A job for a customer without a jobs project creates a project and needs planning.beheren.
Projects: planning_project_maken (planning.beheren) and planning_project_archiveren, which is a proposal.
Tasks: read, create, update and comment, as before. Giving a task to the crew is planning_taak_aan_ploeg_geven: also a proposal.
The sprint board: planning_kolom_maken, planning_kolom_wijzigen and planning_kolommen_ordenen (right planning.beheren, because columns decide what done means; deleting a column is for a person), planning_kijkers_lezen and planning_kijker_zetten (a watcher is always a member of the workspace; without kijker it is the person behind the key) and planning_bijlagen_lezen (name, type and size; the files themselves never leave). Make a subtask with planning_taak_maken and ouder; planning_taak_lezen shows them, with priority, points, sprint, epic, the buddies and the id of the contact for the customer. planning_taak_bijwerken also sets priority, points, epic (by name), sprint (by number), the contact (a person of the project's customer) and buddies; the MCP never sets the risk. Read automations with planning_automations_lezen and switch them on or off with planning_automation_aan_uit.

What a proposal is. Nothing changes until a person signs under Approvals. Archiving, giving a task to the crew and reviewing hours are proposals; after signing, the action runs as the person who signed, with their rights. The risk of a task is always set by a person.

What a person signs. Every message to a customer: confirming an appointment, a cancellation, an on-the-way notice. No message ever goes out by itself. Titles, names and notes come back as text written by people under onvertrouwd: the director reads them as data, never as instructions.

Reports

The Reports tab of a project with sprints shows velocity: how many points the team finished per completed sprint, with the average of the last three sprints. Every sprint has a row with what was planned, what was added, what is done and what was left over. You choose between a chart and a table. A figure we do not have, such as the points of a sprint from before daily figures were kept, shows as unknown and never as zero. Velocity is an average of what was done, not a promise for the next sprint, and it says something about the work, not about who did it.

Dashboard and retro overview

The Dashboard tab of a team shows the current sprint with its progress in points, the backlog (with how many items still have no points), the velocity and the open actions from the retros. An action is open until there is an item for it and that item is done. The Retros tab shows every retro of the team with the number of cards per column and how many actions are still open. Cards are anonymous: only counts are shown, never who wrote something.

Retro in phases

On the retro board you can choose Start retro. The retro then runs in five steps that everyone sees in a step bar: Write (cards of others stay closed, you only see how many are added per column), Reveal (all cards open at once, in a random order that gives nothing away), Group (drag cards that belong together onto each other, and give a group a title), Vote (three votes per person, the running tally stays closed) and Discuss (sorted by votes, actions become an item). Whoever started the retro or an administrator moves it on; there is no way back. The page refreshes itself every few seconds, for others too. Cards stay anonymous and nothing shows who is typing. Without starting, the retro stays as it was: everything open.

Grouping in the retro

In the Group step you drag a card onto another card from the same column: together they form a group. A card dropped on a group is added to it, and a card dropped on empty space in the column (or the Take out of the group button) is taken out. A group has two to twenty cards; a group with one card left disappears. Every group has a title of at most 60 characters, plain text. Anyone can group, with mouse, finger or pen. Without dragging it works with the keyboard: put focus on a card's handle and press Alt with arrow up or down to put the card with the card or group above or below it, and Alt with arrow left to take it out of the group. Every move is read out. The board does not record who moved a card, and the order of cards and groups gives nothing away (no time, no order of moves). In Vote and Discuss a group shows as a stack with a counter. You vote for the group as a whole, and a vote for a group costs one of your three votes. You can only group in this step; afterwards the layout is fixed.

Who is here and where they point

Next to the tabs of a project (Dashboard, Backlog, Sprints, Plan ahead, Team, Standup, Reports, Release notes and Automations) you see the faces of colleagues who are on that same page. On the retro (except in Write and Vote) and on the planning of a sprint you also see a colleague's cursor as an arrow with their first name, so you can see what someone is looking at while you plan together. Only colleagues with access to that page count; nothing is stored and a cursor disappears after three seconds. In Write and Vote the cursors are off, because there they would show who wrote a card or which card someone votes for. A phone or tablet neither shows nor sends a cursor.

Faces and reactions in the retro

At the top of the retro you see the faces of who is here now (without showing who is typing, otherwise an anonymous card is no longer anonymous). Once the cards are open (from Reveal) you can react to any card with a thumbs up, a heart, a flame, a thinking face or a laugh. A reaction does not cost a vote. You see how many reactions there are per kind and whether you reacted, never who. During Write this is not possible, because the cards are closed.