Concepts

Overview#

Attia is built from a handful of records that point at each other. A workspace holds teams, teams own jobs, jobs collect applications, and every application names a candidate. Learn those five and the rest of the product reads as a variation on them.

Basic concepts#

Applications#

Every person who applies for a role gets an application, and that record is where the hiring work happens. A recruiter opens one, reads it, moves it forward, and rejects or hires from it.

The application sits under a job, and the job's team decides which statuses it can move through. Along the way it collects an assignee, labels, comments, a review rating, an SLA deadline, the source it arrived from, and an agent you can hand it to.

Some things an application deliberately does not carry: priority, a due date, sub-applications, or links to other applications. Priority sits on the job. An SLA is how you put a date on a single application.

Candidates#

A candidate is the person. Attia keeps that record once for the whole workspace rather than per team, so someone applying for three roles gives you three applications and one candidate.

An application points at exactly one candidate and one job. That pairing is what joins a person to the work.

Statuses#

Statuses come in two scopes, and the two are easy to mix up.

Application statuses belong to a team. Each team defines the ordered set its applications move through, and those statuses group the applications list and name the columns on a board.

Job statuses belong to the workspace. One catalog covers every team, and only a workspace admin edits it, under Settings → Jobs → Statuses.

Teams#

A team is the group that owns hiring work. It owns its jobs and their applications, its own application statuses and labels, its members, and the views shared with it.

Teams can nest. A new sub-team inherits its parent's application statuses and its privacy setting by default. Turn inheritance off and the team gets local copies of those statuses to run on its own. A team's timezone and its workflow settings, auto-close and auto-archive among them, stay independent of the parent. Those only arrive as copies if you copy them from another team while creating the team.

Workspace#

The workspace is the container for everything your organization hires with. Teams, jobs, candidates, applications, documents, career sites and members all sit inside one, and nothing crosses between workspaces.

Each workspace has its own address, attia.app/your-workspace. It has one owner. Everyone else is an admin or a member, with an optional guest flag for restricted access. One account can belong to several workspaces and move between them from the workspace picker.

Organizing work#

Jobs#

A job is the role you are hiring for, and the record every application for that role groups under.

A job has one owning team, and you can add more teams when other people need access. It carries a title, a description, a status, a priority, a lead, target and start dates, and labels. A new job can start from a template, so a role you hire for often does not get rebuilt each time.

Views#

A view saves a query with its display settings, so the filter, grouping and sort you set once come back the next time.

Each view has a visibility of personal, team or workspace, which decides who else sees it. Views exist on jobs, on candidates, on a team's applications, on the audit log and on career sites.

Documents#

Documents hold the writing no single application owns: hiring briefs, interview guides, scorecards, and the reasoning behind a role. A document lives in the workspace, and one attached to nothing is readable by everyone in it. Attach it to a team, a job or an application and the reach narrows to the people who can see that.

Career sites#

A career site is the public face of your hiring, and it is workspace-level as well. Its Linked jobs decide which roles it lists, so a role reaches candidates only once you link it.

How these fit together#

The short version:

• a workspace holds every team, person and record
• teams own the jobs and define the statuses applications move through
• jobs are the roles you are hiring for
• applications track one person against one role
• candidates are the workspace-level people records applications point at
• views, documents and career sites sit on top of all of it