Organization and team settings
Every settings page is a title over outlined boxes, one per section, each named on its border. Inside a box, a hairline and a name mark a further group, so the controls for adding another entry (users, teams, labels, team members and project access) stand under their own name below the list they add to.
- Org → General: organization name; the organization's address (below); max attachment size; date format (six formats, live preview) applied everywhere; "Workdays start on" — the first workday of the week, which anchors every roadmap column; "Week 1 of the year" (First 4-day week / ISO 8601, week containing Jan 1, or first full week); and "Default plannable hours per week" (below).
- Max attachment size — an organization admin sets the largest single task attachment in Org → General, from 1–20 MiB per file (default 20 MiB). The limit also applies to images uploaded into task descriptions. It follows the task's organization, including when someone from another organization uploads a file to a shared project. It applies to new uploads; lowering it leaves existing files in place. The setting limits each file, without setting a combined storage quota. Team leaders can change it only if they are also organization admins.
- Export data — an organization admin can download the organization's data from Settings → Organization → General → Export data. The ZIP contains JSON records for projects and tasks, including archived work; comments and activity history; people and their organization roles, including inactive people, agents and unclaimed seats; teams and access grants; labels, task relationships, milestones, organization settings and legacy billing metadata when present; and agent-key metadata. Uploaded task attachments, images embedded in task descriptions and uploaded member portraits are included as files. The archive's manifest lists the record counts and maps file records to their saved bytes. Format version 2 names the task records
data/tasks.json; relationships, labels and attachments usetask_links.json,task_labels.jsonandtask_attachments.jsonin the same folder. Related records identify their task withtask_id.Personal inbox messages, task subscriptions, account preferences and private backgrounds are outside the organization export. Passwords, login records, OAuth connections, access tokens and secret keys are also excluded. Agent-key metadata does not include the key or its hash; externally hosted Gravatar portraits are not copied. Billing plans, subscription records, usage ledgers and billing delivery records are outside this work archive. Admins can review current usage in Billing and invoices through Manage billing.
Keep the General page open while Qivo prepares the download. Progress is shown, and Cancel export stops it; leaving the page also cancels preparation. A missing file or failed request stops the download and shows an error as soon as it is detected, so an incomplete archive is not presented as successful. Qivo assembles the ZIP in your browser, so very large exports depend on available memory and must fit the archive limits of under 4 GiB and at most 65,534 entries, including its JSON files. Data is read over the course of the export, so changes made during preparation can appear in different parts of it. This is a portable data copy, without a Qivo import or restore workflow.
- Your organization's address — the name your organization lives under, and the part of the URL that comes after
qivo.io/app/: everything you open readsqivo.io/app/acme/…(§ Links you can share). It is made from the organization's name when the organization is created (lowercased, spaces and punctuation turned into single hyphens) and it is unique across every organization, so if the name you chose is already in use you are given the next free variant —acme, thenacme-2. Two organizations called the same thing therefore never collide. Five things are worth knowing before you change it:- Renaming the organization does not change the address. They are separate on purpose: a name is something you read, an address is something people have saved. Change the address only when you mean to.
- The change is immediate, and it is not forwarded. Every link anyone has bookmarked or shared stops working the moment you save — there is no redirect from the old address to the new one.
- The address you leave becomes free straight away, and another organization can take it. This is deliberate: if old addresses were reserved for ever, an organization could quietly hoard names simply by renaming itself over and over.
- Some addresses are not available. If the one you want is already taken, or is a word reserved for the product itself (
docs,pricing,admin,settingsand about a hundred others), saving tells you which of the two it was and you pick another. There is no "check availability" button, because an address held by an organization you cannot see would always look free — saving is how you find out. - The change is recorded. Moving the address writes a line into the organization's activity naming both the old address and the new one and who made the change, so a colleague who finds their bookmark dead can see what happened without asking.
Only an organization admin can change the address.
Because a released address can be taken by somebody else, the app watches for it on your behalf: if an address you have used before opens a different organization than it did last time, Qivo stops before showing you anything and tells you whose organization it is now. You confirm once, and it doesn't ask again.
- Plannable hours per week — the one capacity number the app plans against: the team strip's 100%, auto-fit's weekly budget and the delay projection's walking speed. It is the time someone has for planned project work — their week minus meetings, email and other overhead — so it is deliberately smaller than a contracted work week, and it is always a whole number of hours (1–168): planning to the half hour was precision nobody had. It belongs to the person, so it follows them into every team and project they work in, and two people in the same team can have different weeks. Two places set it:
- Org → General → "Default plannable hours per week" (32 out of the box) — the week a new user starts on. Changing it never rewrites anyone who already has hours.
- The person's own hours, an inline h/wk field on their row in Org → Users — guests have one too, further down the same page, and theirs is the week this organization plans them at — or on their row in a team's member list. An org admin can set anyone's; a team's leader can set the hours of the people in their own team, without being an admin. It is not self-service: ordinary users can't raise or lower their own planning capacity, and where the field is read-only its tooltip names who can change it.
- Team (Settings → Organization → Teams → the team): name and the team's member list with a per-person Leader checkbox (the leader runs the team; members receive access to projects shared with it, see §12) and each member's plannable week. Team leaders and organization admins can change the team name and membership; permitted leaders can update a member's planning hours. Stale-task, auto-archive and delay-tracking controls are not team settings; team rows retain only legacy threshold data for old records.
- Org → Labels: the organization's shared label list — rename a label and it renames everywhere. Click its color dot to open the color picker; choosing a swatch saves immediately, while Escape or clicking outside dismisses it without changes. Deletion warns with a live "used on N tasks" count. New organizations start with Electronics and Mechanical labels. Anyone in the organization can put a label on a task; curating the list takes an org admin, a project lead, or a user role on some project.
- Team identity: teams, projects and sub-projects are text-only — just a name, no icon, emoji or abbreviation — and there are no per-project or per-milestone identity colors to pick: on task surfaces, the status colors (§7) are the color language, so nothing decorative competes with them.
✦ What sets this apart — Calendar-week configuration is first-class: your org defines what "W32" means and which day a week starts on, and the entire roadmap, week numbering and planning grid follow. Most tools plan by dates and leave week semantics to guesswork.