Roles, people and integrations

Create the user. You give a first name, a last name, an email, a role (the seeded Client role fits most people) and which organisations they belong to. That is the whole form; the company is inherited automatically.

They get a welcome email with a link to the sign-in gateway. If their team is on a Microsoft tenant they use Microsoft sign-in; everyone else asks for a 6-digit code by email. There is nothing to provision and no password to set, so onboarding ends when you hit save.

Then add them to the specific projects they should see. This step is easy to forget and it is the one that matters: clients only see projects they are a member of, so a user with the right role and no project memberships signs in to an empty portal.

Client users are free and unlimited, so there is never a reason to share one login between four people at the client. See pricing for why we do it that way.

In the visual role editor. You name the role (the casing you type is the casing everyone sees) and then work through the per-resource tabs. There are 20 resources: requests, issues, feature requests, change requests, tasks, chats, files, comments, users, roles, organisations, projects and the rest. Each one gets create, read, update and delete checkboxes.

Nobody wants to click 80 boxes, so there are grant-all and revoke-all shortcuts per tab and globally. Start from everything and take things away, or start from nothing and add.

Two settings do the heavy lifting. “Access To” decides which apps the role can open at all (admin panel, team workspace, client portal), and a role is typed either Internal or External, where external roles never see internal items. Organisations and projects also carry a “show all” switch: leave it off and the role sees only what it is a member of, turn it on and it sees everything.

Permission changes apply on the next request. No re-login, no cache to clear: you fix a role and the person’s next click already reflects it.

Project membership is set per project, so somebody whose role lists every project in an organisation can still be closed out of one they are not a member of. Opening it shows an access screen with the project name and a way to ask, rather than an error.

Approving is a permission. Roles carry an Access Requests resource: read decides who sees the queue, update decides who can approve or decline. Client accounts never get it. The queue appears as an Access Requests tab on the project, in both the admin panel and the team workspace, and every project has one.

A request reaches everyone who can decide it, in the app, by push notification and by email. Approving adds the person to the project and to its support chat in one step. Declining asks for an optional reason, which the requester is shown.

Asking is capped at twice a day for the same project and five times in total, so a decline cannot turn into a queue of reminders. Every attempt is kept under Decided, with who decided it and when.

Six internal roles (Admin, CEO, Senior SWE, GM, PM and SWE) and one external role, Client, which can open the client portal and nothing else.

They are there so you can start working on day one rather than designing a permission model first. Most teams use them as they are for a while, then add one or two of their own once they know where the seeded set does not fit.

Building alongside them is fine. Custom roles sit next to the seeded ones rather than replacing them, so you can move people over gradually.

Permissions are set per resource, and each resource carries read, create, update and delete separately. The resources cover requests, issues, feature and change requests, tasks, personal tasks, time and time reports, projects, organisations, members, roles, API tokens, support chat, the error log and access requests.

A role is a matrix, not a tier. You can give somebody every read in the product and no writes, or writes on tasks and nothing else. Two resources gate a whole page: the error log, which is not in the menu at all for roles without read and keeps clearing to senior roles, and access requests, which decides who sees and answers requests to join a project.

Everything is enforced on the server. A resource a role cannot read is not hidden in the interface, it is absent: from lists, from counts, from search and from notification fan out.

A change to a role reaches sessions that are already open. The team workspace and the client portal apply it as it happens; the admin panel applies it when you come back to the tab. And a role that people still hold cannot be deleted. The number of holders is shown instead, so it can be reassigned first.

Organisations hold members and projects. Projects hold their own member list. The two lists are separate on purpose: being in an organisation does not put you in every project underneath it.

What someone actually sees is their role’s permissions multiplied by their project membership. The role decides what kind of thing they can do; membership decides which records they can do it to. The exception is a role with “show all” turned on for organisations or projects, which lifts the membership filter for that resource.

All of it is enforced on the server: lists, counts, search results and notifications alike. A record outside your scope does not come back in your data, so counts do not quietly include things you cannot open and search does not leak titles you were never meant to read.

On the meeting’s Sharing tab, which appears once any meeting has finished. Anyone who can approve project access decides, per person, whether that person may open the recording, the transcript, the summary, or nothing at all.

The tab is not limited to the people who were on the call. Search for anybody, colleague or client, add them, and set their switches: a client who was never named on the meeting can be given the write up, and a colleague who missed it can be given the recording. Sharing with a client puts the meeting on their own calendar and on their home page as well.

Nothing is shared by default. Until somebody decides, the meeting page is locked for a client who attended and they can ask from that locked page with a note. Those requests land in the same tab alongside the note they wrote, and the person who asked hears back by notification and by email once it is settled. Every grant can be tightened again later, and clearing somebody’s switches is how access is taken away.

Two related habits sit alongside it. Whoever set the meeting up chooses whether a transcript is kept at all and whether a write up is made, both switches set when scheduling and changeable mid-call. And deleting a meeting is permanent: it purges the recording, the transcript, the captions and the summary rather than hiding them.

Every project has a Files tab. Upload the documents the team should be able to find in one place, save links and write formatted notes beside them, then decide for each one whether it stays with the team or is shared with the client organisation.

Sharing is a deliberate step rather than a consequence of uploading. It needs the right permission, it is done one item at a time, and it is written into the project’s activity timeline with who did it and when. Changing a link or a note the client can already see needs that same permission. Clients see only what was shared with them, and the rest is absent from their view rather than sitting behind a control.

That activity timeline is worth knowing about on its own. It groups a project’s history by week and covers work items that changed, members added or removed and by whom, meetings that took place, files, links and notes shared, and changes to the project’s secrets register. It is the audit answer at project altitude, next to the record-by-record trail that already exists on every item.

Per project, with three things: the repository owner, the repository name, and a fine-grained personal access token that has Issues read and write on that repo. Nothing broader is needed, and nothing broader should be given.

The token is validated against GitHub before it is saved, so a typo fails at the point you make it rather than three days later. It is then stored encrypted and never shown again. If you lose it, you issue a new one.

From then on the mirror runs one way. New issues, feature requests and change requests appear as GitHub Issues, with labels carrying the type and the priority. A closing status (closed, cancelled or rejected) closes the mirrored issue; anything else reopens it, so a reopened record does not leave a stale closed issue behind.

The mirror never blocks or slows the helpdesk write. If GitHub is having a bad day your record still saves. Disconnecting a project stops new mirroring and leaves the existing links intact.

You define a maintenance period per project: the window a retainer or support agreement covers, a monthly allowance in man-days, a description of what it covers, and the cost if you want it on the record. The record is the agreement, and the agreement is all it holds.

What has been spent against it is never typed in by hand. It is read from the time your team tracked on that project’s own tasks, issues and feature or change requests, totalled when the figure is asked for. Two things shape it. The month is clamped to the window, so a period that starts mid-month counts from the day it starts rather than from the first. And only counted time is in it: a timer still running, and an entry the safety layer closed that nobody has confirmed, both stay out.

Clients see the same agreement on their own project, plus the month’s usage against the allowance, always as an aggregate and never broken down per person.

Projects that predate tracked time keep their hand-written hours as read-only history below the agreement. Nothing can be added to it, and nothing in it moves the figure, because the totals no longer come from there.

Edit the project. Two fields matter: the contracted man-day total, which is what the team workspace Time tab measures against, and the toggle that decides whether the client sees any of it.

Alert recipients are configurable per threshold, so the 80, 90 and 100 percent alerts do not have to reach the same people. Each one fires once.

The client-visibility toggle is off by default. Turned on, the client portal shows the project’s total in man-days and a rollup by record. It is never broken down by person, and records that are internal to the delivery team do not get their own line.

No. Each user generates and revokes their own tokens in the team workspace Settings. There is no admin screen listing everyone’s tokens, and that is deliberate: a token is a person’s own credential, not a shared key you hand out.

What you control as an admin is the roles behind them. MCP requires team workspace access, so a role without it can never use MCP at all. A client role, for instance, has no path to it no matter what token exists.

Beyond that, an agent only ever gets the permissions of the user whose token it is holding. It cannot read a project that person cannot read or close a record they cannot close. If you want to narrow what an agent can do, you narrow the user’s role.

Setup, scopes and revocation are covered in the team workspace FAQ.

For the parts that get argued about, yes. Every previous version of a title and description is kept with the record when someone edits it, so the wording someone signed off on is not lost when it is rewritten. That holds whether the edit came from the web app or from an AI agent working over MCP: the same history, the same record.

Triage is stamped too. Every sorted request carries who sorted it and the optional reason they gave, which is usually enough to settle why a request became a change request rather than an issue.

Membership is visible in the admin panel: who added a user to an organisation or a project, and when, is there on the record rather than something you have to reconstruct.

Assignment and status changes notify the people affected rather than sitting quietly in a log. The person who now owns the work finds out because they were told, not because they checked.