Signing up
Registration starts with one field: your email address. An email arrives with a link, and the password is chosen only after you follow it. Until the link is opened, the account cannot be used. That way nobody picks a password for an email address they cannot open.
The link from the email works for a limited time. If no email arrives, check the spam folder and register again. If the address is already registered, the product says so by email rather than on screen, so the registration form reveals nothing about who has an account.
Disposable email addresses are not accepted. Register with an address you will keep: invitations, password recovery and emails about your company's state all land there.
Creating a company
A company is created once and gets two permanent properties:
- A subdomain: 3 to 30 characters, Latin letters, digits and hyphens. This is the company's address:
yourcompany.quevell.com. The subdomain is held for as long as the company exists. - A name: up to 200 characters, shown to users in the interface.
A new company starts a 30-day trial with everything the product has. One email address can begin at most three free trials, ever: what counts is trials begun, not companies that exist now. For that count, name+tag@domain is the same email address as name@domain: a separate account on such an address can be registered, but a fourth trial cannot be started from it. For gmail.com and googlemail.com, dots in the name are ignored in the count as well. The owner of a company that already pays is not subject to this limit.
Inviting users
Users are added by a company administrator, or by anyone granted the right to manage users: a name, an email address and a role. The invited user gets an email with a link and chooses a password through it, the same way as at sign-up. Until the first sign-in the user is listed as added; after it, as active.
A user is in one of four states: added, active, deactivated, deleted.
Deactivation blocks sign-in. Everything the user did stays in the record under their name, and the reason for the deactivation is kept with it. Access can be restored, and the user picks up where they left off.
Deletion is a second, separate step: only a deactivated user can be deleted. First everything the user holds moves to a successor: see handover and access. While any of it has not been handed over, deletion is blocked.
The deletion itself erases the personal data: the email address, the photo, the city, the timezone, the profile fields, and it replaces the name with an anonymous label, one for the whole company. The records stay where they are: issues, comments, attachments, rows of the trail. Only the name shown beside them changes. This cannot be undone: the product keeps no copy to restore a name from. The action is confirmed by typing the user's address.
An invitation that was never used can be withdrawn in one step: the link stops working and the address is free again. The same user can always be invited back, and their earlier record comes back with them.
Roles
A company has two roles, and its administrators are a group:
| Role | What it means |
|---|---|
| User | Works in the projects they have been given access to. No say over the company's settings. |
| Trusted user | Grants nothing by itself. It is the right to request administrator rights for a limited time, and every such request is recorded. |
| Company administrator | Not a role: a member of the "Super-admin" group (Administration, Groups). Configures the company: users, rights, projects, automation, system settings. |
Each project has its own roles, assigned separately to a user or a group:
| Project role | What it can do |
|---|---|
| Viewer | See the project. |
| Contributor | Create and edit issues, change statuses, comment, attach files, log time, write in the project's knowledge base. |
| Project administrator | All of the above, plus access management, boards and issue security. |
Individual rights on top of the roles are granted one at a time: reading the company-wide automation Journal, for instance, or viewing the organization chart.
There is more in Rights and access: what each role gives, how a request for administrator rights for a window works, and what is written to the audit trail.
The first project and the first issue
A project is created by whoever holds the right to create projects; the creator becomes its administrator. A project has two mandatory properties:
- A key: 2 to 10 uppercase Latin letters and digits, starting with a letter. Issue numbers are built from it:
OFFICE-13. - A name.
A new project arrives with a standard set of issue types, fields and a workflow, all of it adjustable afterwards. An issue requires two things: a summary and a description. The description is always required, imports included: an issue without one is an issue whose meaning a month later only its author remembers, and not reliably.
Names in other languages
A company names its own fields, statuses, issue types, workflows and transitions, and can give each of them a name in the product's other interface language. Under the Name box there is a checkbox, Names in other languages; ticking it opens a row for a second name.
Everybody sees the name in their own interface language. Where their language has no name, the product shows the one the thing was created under: a label is never empty.
The values of a dropdown work the same way. Above the list of values there is one checkbox, and it opens a second box on every row. A company either translates its dropdown or it does not, and the question is worth asking once.
A translation is removed by clearing the box and saving, or by unticking the checkbox and saving. There is no separate button, and nothing is lost until you save: ticking the checkbox again brings the text back. Having just one name is fine: a company in one language names things once, and the product does not nag about it.
The names in the product's own dictionary (the system fields Summary, Description, Assignee and every label of the interface) are not renamed: the product ships in two languages.
Seats and service accounts
The plan counts seats: how many users may change data. The trial includes 10 seats. One invitation beyond the limit goes through, with a warning on screen: a company that outgrows its plan while it is still bringing people in should hear about it once, not be stopped halfway. The next invitation beyond that is rejected.
Service accounts, the identities integrations and automation rules act as, are counted separately and take no seat from a user: 5 on the trial, 1 on the free plan. Their requests are rate-limited; the numbers and how they are counted are in Limits in the API article.
The end of the trial, and the free plan
A week before the trial ends, and once more the day before, the owner and the administrators get an email, if more seats are held than the free plan will keep. On the day itself nothing switches off: every feature stays, the company moves to the free plan and gets 5 seats instead of 10.
Who holds the seats is decided on the users screen by whoever holds the "Edit seats" right: the owner and the company administrators. Once, on the day of the move, the product fills the seats itself: the owner and four others; after that, nobody changes them but you.
Users outside the seats read everything: every screen they could open before, search, the record, the journals their rights cover, and they can export data until the company's last day. What they do not get is writing: no issue, no comment, no status change, no file, no worklog.
A paid period
Payment is by invoice. How many users and service accounts are paid for, and for which period, Quevell records from the paid invoice; who holds the seats is the company administrator's decision. To change the number of seats or pay for the next period, write to billing@quevell.com.
When a paid period ends and the next one is not paid, the company moves to the free plan the same way as after the trial. A week before the end and the day before, the owner and the administrators get an email if more seats are held than will remain. On the day itself nothing switches off: the seats are assigned, and users outside them read and export data but do not write. The owner keeps a seat first, then the users who held seats before, the most recently active first, then everyone else. So a choice the administrator made stays in place each time a paid period ends.
If the next period starts the day after the previous one ends, nothing ends and no email is sent. If a paid period ends while the trial is still running, the company is back on its trial until the trial's own end.
If fewer seats are paid for than are held now, nobody is moved automatically: while there are more users than seats, the choice is the company administrator's.
When nobody signs in
A company nobody has signed in to for three months gets a warning email, then is archived. An archived company is closed for work, but exporting data stays available. 30 days after archiving, the data is deleted for good. A single sign-in resets the countdown to archiving.