People, roles, and who sees what

Admins, members, field workers and guests; inviting someone by email; letting a guest into one project or one client; and when someone leaves.

Access in sjTasks is two dials, kept deliberately separate:

Role — what you are allowed to do.
Scope — where you are allowed to do it.

Two dials instead of one long list of permissions is what lets a guest from one of your clients sit in your team seeing one project and nothing else.

The three roles

Role	Can do	Scope
Admin	Everything in the team: people, projects, watchers, settings	Always the whole team
Member	The work — create, edit and finish tasks, upload files, write notes, log time	The whole team, only named projects, or only the work assigned to them (a field worker). The admin chooses when inviting
Guest	Read, and write notes. Nothing else. No creating, editing, finishing, or uploading	Always limited to named projects. Never team-wide

There is no separate "owner" role. Somebody has to be able to close the team and somebody has to receive the bill, and that person is recorded — but in the role picker they are simply an admin. One fewer concept to explain.

Only admins and members can be assigned work or have time logged against them. A guest is never offered in an assignee list. A field worker is a member, so they are always offered.

Scope belongs to the person, not the project

There are no private projects. A project is not hidden from some people and shown to others; instead, a person is either team-wide or scoped to a list of projects — or to a client, which is every project of that client, including the ones added later.

That is a deliberate trade. It means an admin can always see all of their own team — which matters the moment you are supporting somebody and need to know your view is complete — and it means there is exactly one rule to reason about:

You can see a project if you are an admin, or a team-wide member, or you have been added to that project by name, or given its client.

Everything else follows from it. What tasks you see, what files you see, what a search returns, what a saved view counts, who is on a watcher list: all the same rule, so there is never a second place for access to go wrong.

The same rule decides who you can see. An admin or a team-wide member sees everyone on the team. A person scoped to projects sees the admins, the team-wide members, and whoever is on a project they share — on the reports, in the pickers, everywhere — and never the rest of the roster. Team settings, where the whole team is listed and managed, is the admins' page and nobody else's; it is not in anyone else's menu.

There is a third setting on that dial, for the person who does not need the team at all.

Field workers: their own work and nothing else

A member can be scoped to only the work assigned to them. Use it for the people who do the job rather than run it — a crew on site, an installer, a subcontractor, a freelancer you hand one piece to.

They see the tasks you give them, and nothing else. Not the project, not its other tasks, not who else is on the team, not your other clients. Assign them a task and it appears; take it off them and it is gone.

What they can do is the whole job and no more:

Move a task through the statuses, including finishing it
Write a note on it — what happened, what was wrong, what is needed next
Put files and photographs on it, which is usually a picture of the finished work
Log their hours against it, when the team has time tracking on

What they cannot do: add a task, change a title, a date, a priority or an owner, open a project page, board or calendar, run a report, or see anybody else's work.

They take a seat, like any member, and they are on every plan: on Free they count among its 5 people, and on a paid plan people are unlimited.

Two practical notes. They are assignable in every project of the team, so you never have to add them anywhere first — giving them the task is what lets them open it. And they are notified about their own work as anyone else would be, so the job reaches them without you chasing it.

When a member's new tasks need an OK first

Some teams want one person's ideas to reach an admin before they reach the list. There is a switch for it on each person, in Team settings: Tasks need approval. It is off for everybody, on every team, until an admin turns it on, and a team that never wants it never sees it. A task raised by somebody it is on for says Waiting for Admin Approval and stays out of every number until an admin says yes; Urgent goes straight through.

Tasks that need approval is the whole of it: what both sides see, what it does to the counts, and why there is no Reject.

Inviting someone

Team Settings, from the menu with your team's name in it. People come first on that page: everyone who is here, then the invitation form. Admins get an invitation form with three things in it:

Their email address. This is fixed on the invitation — the link cannot be turned into a seat under a different address.
A role — admin, member, or guest.
Where they can work. Admins are always team-wide, so the choice disappears. Guests are always project-scoped, so the choice locks to specific projects the moment you pick Guest. For a member you choose: the whole team, or a list of named projects you tick. When your team uses clients, Or whole clients sits beside the projects: tick Acme and they get every Acme project, now and later.

Press invite and an email goes out with a link that is good for seven days.

What they see

The link opens a page that names your team, who invited them, and — if they were given specific projects — which ones. What happens next depends on who they are:

No account yet: they choose a name and a password, tick the box that agrees to the Terms of Service and Privacy Policy, and choose their second sign-in step — a code by email is the default, a code by text message or an authenticator app if they prefer — and they are in. No email verification step: opening mail sent to that address already proved the address is theirs.
Already have an sjTasks account: they are asked to sign in, and joining finishes itself.
Signed up at the front door instead: nothing is lost. Once they confirm their address, the first page lists every team that invited it, yours included, with Join.
Signed in as somebody else: the page says so, and says which address the invitation is for, rather than failing at them.
The link has expired, or has already been used: the page says which, and what to do about it.

If you already have an account

You do not need the email. Signed in, an invitation sent to your address waits at the top of your dashboard — You are invited to Acme, with what you will be able to do — and in the menu under your team's name, under Invited to. Join puts you on that team and takes you there; your other teams stay as they were. Not now puts it away. The team's admins see that you declined, and if they send it again it comes back. Beside the invitations is a link to start another team of your own, if that is what you came for.

Only invitations sent to the address you sign in with are shown, never anyone else's.

Before they arrive

Team Settings lists everyone invited who has not joined yet, with who invited them and how long the link is good for. An expired row says "Expired 3 Sep — send it again". Two controls sit on each row:

Resend — a fresh link and seven more days, to the same address.
Withdraw — the link stops working immediately.

If the person pressed Not now in their app, the row says Declined and the date. Resend asks again.

A team sends up to 20 invitations an hour and 100 a day, and so does each person sending them, guests and resends included. Referral links sent from Refer a team count toward the same number. Past that, the refusal says when there is room again.

The common case: letting someone from a client in

A client is an organisation; a guest is a person. You run a team with ten client projects, and Kim from Acme should see the Acme project only.

Invite Kim by email.
Give her the role guest if she should read and discuss, or member if she will actually do work.
Tick the Acme project, and nothing else — or, if your team uses clients, tick the client Acme so she also sees the next Acme project the day you add it.

She signs in, sees the Acme work, and can write notes on it. She cannot see your other clients' work, cannot find it in search, and cannot see it in anybody's shared view. A guest with no projects yet sees nothing at all, which is the right default for an invitation that has been sent but not yet set up.

Guests, precisely

A guest can: read every task, note, and file in their projects; write notes; edit and delete their own notes; open and download files; follow or stop following a task so they hear about the thread they are in.

A guest cannot: create or edit a task, finish or reopen one, change a priority or a date, upload or remove a file, log time, be assigned work, or change anything about the project.

The interface reflects this rather than arguing with it — the buttons a guest cannot use are not shown, so nobody is invited to click something that will refuse them.

When someone leaves

People leave — a contractor's engagement ends, a client project wraps up, someone moves on. In sjTasks you deactivate them: Team Settings → People, the … menu on their row, Deactivate. There is no delete, on purpose.

What happens, immediately:

Their access ends. They are signed out everywhere, and nothing in your team will open for them again until you say so.
Their open tasks are handed back. Anything assigned to them that was still open becomes unassigned, and each task's history says why — took Jane off it — deactivated — so nothing they were carrying quietly disappears with them.
Everything they did stays. Every task they created, every note they wrote, every hour they logged and every change they made keeps their name on it. The record is your team's, and an invoice that rests on their logged time still adds up.
They stop hearing about your work. No more notifications, no summaries, and their name comes out of every assignee list, watcher list and menu.

What deliberately does not happen: nothing is deleted, and the door is not locked forever. Reactivate, in the same menu, turns their access back on exactly as it was — same role, same projects, same clients. The tasks they were taken off are not handed back automatically; those have had a life in the meantime, so reassigning them is a decision, not a default.

If they open sjTasks after being deactivated, they see one plain page saying their access was turned off and by whom — or, if they belong to another team, they simply land there.

Changing a role is the same menu: make a guest a member, a member an admin, or the other way. A guest who becomes a member takes a seat, so on a full plan the change is refused with the same sentence an invitation would get. Remove takes somebody off the roster for good; it hands their open tasks back the way deactivating does, and the team's history says who did it. Everything they made stays with their name on it either way.

You cannot deactivate yourself, and the team always keeps at least one admin who can run it. And if someone ever asks us to erase their personal details entirely, we can do that on request: their work stays, attributed simply to "Former member".

Your own details, and the team's

Your name, email address, password, timezone, text messages and where you are signed in are on Profile, under your name at the top right: Your account. Signing in, and the second step every account has, is Signing in and two-step sign-in.

The team's timezone and the day its week starts on are in Team Settings → Dates and times, and only an admin can change them. Week start is team-wide on purpose, so that "this week" means one thing to everybody reading the same list; the team timezone is what the daily and weekly summaries go out on, and what anyone without a zone of their own reads.

The team's features — time tracking, subtasks, task lists, watchers, clients, custom fields, billable and Answers from your work, all off until a team wants them, and tags and Ask in English, on from the start — are in Team Settings → Features, and they are an admin's to switch on or off too. Nothing an admin can want is behind a request to us: see Turning time tracking off.

Sometimes the quickest way to help is for one of us to look at sjTasks exactly as you see it. When that happens, it is visible, short, and limited:

You would see it. A black bar sits across the top of every page for the whole time, naming who from sjTasks is signed in as you, with a Stop button on it. There is no quiet version of this.
It ends by itself. A support session is capped at 30 minutes; after that we are signed out whether or not we remembered to leave.
Some things are off the table. While signed in as you we cannot delete anything, change your password, your name or your email address, remove or change anyone's role in your team, grant staff access, change your sign-in step, or agree to texts for you. Those are refused outright, not merely discouraged.
It is written down. Every session is recorded: who, whose account, when, and what was done. Anything changed while we were there shows up in the task's history like any other change.

We do it to answer a question you have asked us, and we will tell you when we have. Nobody at sjTasks ever needs your password for this, so nobody will ask for it.

More than one team

If you belong to more than one, the menu with your team's name in it switches between them. Nothing crosses over: projects, people, files, notification settings and search all belong to one team.

Your role and your scope belong to one team too, and so does whether your new tasks wait for an OK. You can be a member on one team whose work needs approving and an admin on another who does the approving, and neither team learns anything about the other.