Business plan: portfolio, client workspaces and issue sync

The Business plan is everything in Team, plus the three features on this page. It is $35 per editor per month paid yearly ($420 per editor per year), or $40 per editor per month paid monthly. A workspace owner upgrades on the Billing page: see plans, seats and billing.

A workspace that is not on Business sees a short explanation in place of each feature, with a link to the Billing page for owners.

The portfolio view

One page with every open project, so you can see which rollouts need attention without opening each one.

1. Open your workspace and choose Portfolio in the menu.
2. The row at the top counts open projects, go-lives in the next 30 days, projects at No-go with 30 days or less to go, late tasks and open critical issues.
3. The list has one line for each project: its current phase, go-live date and days to go, readiness percent and Go or No-go, tasks done, late and blocked tasks, open critical and high issues, exit criteria met in the current phase, payroll runs within tolerance, and when it was last updated. Click a project's name to open it.
4. Use Sort by to order the list by go-live date, readiness, late tasks or critical issues.
5. Press Download as CSV for the same list as a file for a spreadsheet.

• Every figure is worked out the same way as on the project's own pages, so the two always agree.
• Owners, Editors and Contributors of the workspace can open the portfolio. Guests cannot.
• If the workspace has client workspaces, the portfolio also covers the ones you are a member of, and Show workspace narrows the list to one of them. A client workspace you do not belong to is left out.
• It shows up to 200 projects. Beyond that, the ones going live soonest are shown and the page says so.

Client workspaces on one bill

For consultancies and agencies. Each client gets a workspace of its own, with its own projects, people, templates and activity log, and all of them are paid for through your workspace, which we call the home workspace.

Create a client workspace

1. Open the home workspace and choose Clients in the menu. Owners and Editors of a Business workspace see it.
2. Enter the client's name and press Create client workspace. Only an Owner of the home workspace can do this.
3. You are the new workspace's owner. Open it, create projects, and invite the client's people from its People page as you would in any workspace.

A home workspace can have up to 50 client workspaces. A client workspace cannot have client workspaces of its own.

Seats and the bill

• A client workspace is on the home workspace's Business plan. It has no card, plan or invoice of its own, and its Billing page says which workspace it is billed through.
• You buy one editor seat for each different person who is an Owner or Editor in the home workspace or any of its client workspaces. Someone who works in five of them needs one seat. An editor invitation that is waiting counts. Contributors and Guests are free.
• The Clients page shows how many seats are in use across the group. When every seat is in use, an Owner of the home workspace adds a seat on its Billing page.
• Each workspace has its own 3,000 AI credits a month.

Who can see what

A client workspace is walled off like any other workspace. Being an Owner of the home workspace does not let you into a client workspace: you see its projects only if you are a member of it. On the Clients page, an Owner or Editor of the home workspace who is not a member sees the client workspace's name and how many projects and members it has, and nothing else. The client's people see their own workspace and nothing of yours.

Release or delete a client workspace

• Release: on the Clients page, press Release next to the workspace and click again to confirm. It leaves your bill, keeps all its projects and people, and becomes an ordinary workspace on the Free plan, which its owners can then upgrade themselves.
• Delete: open the client workspace and delete it from its Settings page, as for any workspace.
• A home workspace that still has client workspaces cannot be deleted. Release or delete them first.

If the home workspace leaves Business

Nothing in a client workspace is deleted. Each client workspace is held to the Free plan's limits (1 project and 2 editors): everything in it keeps working, but it cannot add projects or editors. It gets Business back when the home workspace is on Business again, or you can release it so that it can have a plan of its own.

Issue sync

Issue sync sends issues to any tool that can receive a web request, and accepts status updates back. That can be an automation tool that offers an incoming web address, or an address your own IT team runs. It is not a ready-made connection to a named product: someone has to set up the receiving end. Native Jira and ServiceNow connections are planned.

Turn it on

1. Open the workspace's Settings and find Issue sync. Only Owners see it.
2. Enter the address to send issues to and press Turn on issue sync. The address must start with https://, use the standard port (443) or port 8443, and be on the public internet. Addresses on a private or internal network are refused.
3. HRjects shows the signing secret once. Copy it and give it to whoever sets up the receiving end. It is not shown again. If it is lost, press Make a new secret; the old one stops working at once.
4. Press Send a test. Settings shows whether the last delivery succeeded and, if not, why.

From then on, when an issue is logged, changes status or is removed in any project of that workspace, HRjects sends a message after the change is saved. Each workspace has its own setting, so a client workspace is set up separately.

The message contains the issue's title, module, severity, status and owner as people typed them, and the name of the person who made the change. Only use an address you trust.

What to expect from delivery

• Sending never holds up or fails the person's change in HRjects.
• The receiving end should answer with any 2xx status within 5 seconds. Redirects are not followed.
• A delivery that fails is tried up to 3 times, a few seconds apart. Delivery is best effort: messages wait in the server's memory, so one that is waiting when HRjects restarts is lost, and a message that fails all 3 tries is not sent again. Use the CSV download on a project's Issues workspace if you need to check nothing was missed.
• At most 60 messages a minute are sent for one workspace. Beyond that, messages are left out, and Settings says how many.
• After 20 failed deliveries in a row, issue sync pauses and Settings shows Turn back on.

Reference: the message HRjects sends

A POST with Content-Type: application/json and this body:

{
  "event": "issue.created",
  "sent_at": "2026-10-12T09:30:00.000Z",
  "workspace": { "id": "0b9c…", "name": "Acme HR" },
  "project": { "id": "5d2e…", "name": "Payroll rollout" },
  "issue": {
    "id": 42,
    "title": "Overtime rate wrong for night shift",
    "module": "Payroll",
    "severity": "High",
    "status": "Open",
    "owner": "Sam"
  },
  "changed_by": "Dana"
}

• event is issue.created, issue.updated (the status changed), issue.removed or test. A test message has null for project and issue.
• severity is Critical, High, Medium or Low. status is one of: Open, In progress, Resolved.
• Headers: X-HRjects-Event repeats the event. X-HRjects-Delivery is an id that is the same for every try of one delivery. X-HRjects-Signature is described below.

Reference: the signature

Every message carries the header X-HRjects-Signature: t=<unix seconds>,v1=<hex>. To check it:

1. Take the number after t= and the body exactly as it was received, byte for byte.
2. Join them with a full stop: <t>.<body>.
3. Work out the HMAC-SHA256 of that text with the signing secret as the key, written as lower-case hexadecimal.
4. Compare it with the value after v1=, and refuse the message if they differ or if t is more than 5 minutes from the current time.

Reference: sending a status back

The other system can set an issue's status by sending a POST to the inbound address shown under For whoever sets it up in Settings. It ends in /api/hooks/issues/ and the workspace's id.

{ "project_id": "5d2e…", "issue_id": 42, "status": "Resolved" }

• Use Content-Type: application/json, and the project.id and issue.id from a message HRjects sent.
• Sign it the same way, with the same secret: an X-HRjects-Signature header of t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>.<body>">.
• The change goes through the same checks as one made in the app and appears in the project's activity log as made by Issue sync. It is not sent back out to you.
• Only the status can be changed this way. Issues cannot be created, edited or removed from outside.
• The same signed message arriving again within 5 minutes is acknowledged and not applied twice.

Answer	Meaning
200	The status was set, or the message was a repeat of one already applied
400	The body is missing a field, or the status is not one of the three
401	The signature is missing, wrong or out of date
403	Issue sync is off for the workspace, or the workspace is not on Business
404	No such project or issue in this workspace

Without the Business plan

On every plan, anyone who can see a project can download its issues as a CSV file from the Issues workspace. See logging issues.

Related: plans, seats and billing, roles and editor seats, and what issue sync sends.