TaskingerA workbook is a boundary, not a folder
In most tools your contexts are projects, boards or pages inside one shared space, and separation is a matter of remembering to share the right thing with the right person. In Taskinger a workbook is the unit of storage and of access. Every task, note, project, file and team belongs to exactly one workbook, and every workbook has its own list of members. A member record is what grants access; without one, the workbook does not exist for you, not even as a name in a list.
Deny by default, on the server
Access is decided by security rules that run inside the database itself, on every read and every write, before any data leaves Google's servers. The rules start from "no" and allow an operation only if the caller is signed in, is a member of that workbook, and carries the flag the operation needs. In simplified form:
allow read: if isolated(workbook) && (member.can('readAll') || task.assignee == me);
allow write: if isolated(workbook) && member.can('assignOthers');Because the check happens in the database, it cannot be skipped by a modified client, a browser extension or a script talking to the API directly. The interface only ever reflects what the rules already allow.
What a member can see
Membership alone does not show you everything. Each member has a role and eight permission flags, and the plainest member sees only the tasks assigned to them plus the notes they may read. Teams narrow it further: a lead sees their team and its sub-teams, an employee sees their own segment, the owner sees everything. The flags are stored on the member record, so changing a person's rights in one workbook changes nothing about their rights anywhere else. The full permission matrix is on the teams page.
Invites, teams and the API
People join a workbook only through an invitation link created by someone with the "Manage members" flag; links are private, token-bearing URLs that can be revoked. Teams live inside the workbook and cannot span two of them. The KPI API, available on the Team plan, works with keys the workbook owner creates for that workbook alone, revocable at any time, and it is served by functions that check the same membership and the same flags.
Proven on every change
The rules are covered by an automated test suite that runs before every deploy. The tests try exactly what an attacker would: reading another workbook's tasks with a valid account, escalating a member's own flags, reusing an invite, reaching a frozen workbook, moving a file between workbooks. A failing test stops the deploy. The count changes as the product grows, so we do not print a number; the principle does not change.
What isolation does not do
Isolation is about access between members, not end-to-end encryption. Data is encrypted at rest and in transit by Google Cloud, but the operator can technically access it under the conditions in the privacy policy, for example to delete an account on request. A member you have granted "See all tasks and notes" sees all tasks and notes in that workbook; the flag does what it says. And a person who is a member of two of your workbooks sees both, because you made them a member of both.
One account, all your worlds
The point of the boundary is that you do not have to live behind it. One sign-in lists every workbook you belong to: Home, the company, the side business, a personal one nobody else sees. Switching takes one tap, and the app remembers where you were. Two workbooks you create and three people you add are free; the security is the same on every plan. See how that compares with Todoist, Trello, Notion and Google Tasks.