Getting started
Create a workspace, invite your team, and get a first project running properly rather than provisionally.
The hierarchy
Everything in Krrim sits under three levels:
Organization → Projects → TasksYour organization is the workspace. It has its own subdomain
(acme.krrim.com) and — importantly — its own database schema. Data from
different organizations is separated at the database level, not by a WHERE
clause somebody has to remember to add.
Create your workspace
Sign up and pick a workspace name. The slug you choose becomes your subdomain and cannot be changed later, so pick the company name rather than the name of the project you happen to be starting with.
Set your timezone in workspace settings straight away. It decides when recurring tasks fire, when due dates roll over and when standups open — all of which mean "09:00 where you are", not "09:00 UTC".
Invite your team
Settings → Members. Invite by email and pick a workspace role:
| Role | Can |
|---|---|
| Owner | Everything, including billing and deleting the workspace |
| Admin | Manage members, projects and workspace settings |
| Member | Work in the projects they belong to |
| Guest | See only the projects they are explicitly added to |
You can change a role later. See Team and roles for what each one means in practice, and Guest access before you invite anyone outside the company.
Create a project
Projects → New project. Give it a name and a short key — APOLLO,
WEB, OPS. The key prefixes every task in it and cannot be changed
afterwards, because task keys are built from it and people paste those into
chat.
A new project arrives with a working set of statuses, task types and priorities. You do not have to configure anything before you can use it.
Add real work
Resist the urge to configure first. Add ten real tasks, work them for a few days, and then change the statuses — you will know what you actually need rather than what seemed sensible on day one.
Press C anywhere to create a task.
What to set up once you have used it
In rough order of how often teams find they want them:
Workflows and statuses
When the default columns stop matching how work actually moves.
Custom fields
When you find yourself putting the same structured thing in descriptions.
Project templates
When you are about to configure a third project the same way as the first two.
Integrations
When Krrim needs to know about something that happens elsewhere.