DEV Community: Kayabyte

Onboarding in Confluence: make new hires watch the right spaces automatically

Kayabyte — Sun, 01 Nov 2026 23:08:13 +0000

A new hire should see what their team writes from day one: the team space, the handbook, the incident log. In Confluence Cloud, watching is a personal setting, so nothing happens when someone joins the team. Here is what you can do with Confluence alone, and where it stops.

What new hires get by default

Autowatch is on by default, but it only covers pages a person creates, edits or comments on. A new hire watches nothing in the team space until they have worked on a page there.
Watching a space covers all its pages and blog posts, and the person has to switch it on (or an admin does it for them, see Option 3).
Watching does not give access. If the space is restricted, the new hire has to be able to see it first.

Option 1: a step in the onboarding checklist

Put a short "Follow these spaces" section on the onboarding page, with a link to each space and one line: open the space, select Watch. It costs nothing and works for a handful of spaces and one or two hires a month. It breaks when the list of spaces changes, when people skip the step, or when a new hire joins a team that follows eight spaces. Nobody checks that it was done.

Option 2: @mention on the key pages

For the few pages everyone must read, mention the new hire in a comment or add them to an announcement page. That is not a continuous feed from the space, and it is a manual job for each person.

Option 3: an admin adds the watch

The REST API can add a watch for someone else, one account at a time. It needs the Confluence Administrator permission, or Space Administrator on that space, plus the header X-Atlassian-Token: no-check:

curl -s -o /dev/null -w "%{http_code}\n" -u "you@example.com:your-api-token" -X POST \
  -H "X-Atlassian-Token: no-check" \
  "https://your-site.atlassian.net/wiki/rest/api/user/watch/space/TEAM?accountId=NEW_HIRE_ACCOUNT_ID"

A 204 means the watch was added. Run by hand, it is one more onboarding task. Run on a schedule, it needs somewhere to run, and it cannot tell watches it added from watches people chose: someone who unwatched on purpose is added again, leavers keep watching, and a cleanup step does not know which watches it may remove. I wrote the whole script and its limits in How to make a Confluence group watch a space. If you prefer a ready-made one, there is a free MIT script here: github.com/kayabyte-2/atlassian-admin-scripts.

Option 4: let group membership drive the watches

If you already keep a group per team (say engineering), the cleaner design is that adding someone to the group makes them watch. Full disclosure: we build Group Watchers, so weigh this accordingly. Group Watchers works like this:

A rule maps one or more groups to a space or a single page. A space can have several rules.
Joiners: add the new hire to the group and the app adds their watch. It checks membership every hour, and right away when you change a rule or select Sync now.
Access: members who cannot see the space are skipped and counted in the rule status, then checked again every 6 hours, so a hire who gets space permission a day later still ends up watching.
Leavers: when someone leaves every group in a rule, the app removes the watch it added. You can switch that off, and watches people had before are never removed.
If a new hire unwatches, the app does not add them back.
It runs on Atlassian's Forge platform and makes no calls outside Atlassian.

Two limits: only Atlassian user accounts can watch, so portal-only customers and app accounts are skipped. And if an identity provider fills your groups, the new hire appears when your provisioning puts them there, so check how quick that is.

One more thing: will they get email?

A new watcher may see little in their inbox. Edits and new pages go into the daily digest by default, while comments are emailed straight away. Each person changes this under their profile picture, Settings, Email. Add one line about it to the onboarding page.

Which one to pick

A few spaces and rare hires: the checklist.
Key pages only: @mention.
Many spaces, frequent hires, groups you already maintain: group-driven watching, with a script you run or an app.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Client budget alerts in Jira before the hours run out

Kayabyte — Sun, 01 Nov 2026 21:14:22 +0000

A client has 120 hours. You find out at 118. By then the only conversation left is the awkward one. What you want is a warning at 80 or 90 percent, early enough to talk about scope, a change request or a pause.

Jira tracks the hours, but it has no concept of a budget, so there is nothing to alert on out of the box. Here is what you can build with the built-in tools, and where each option stops.

Step 0: decide what the budget is

Before any tool, write down three things per client: the number (hours or money), what it covers (a project, an epic, a version), and the period (one-off, or resets every month). Every option below breaks if this is vague.

Native option 1: time tracking fields and a filter

Each work item has Original estimate, Remaining estimate and Time spent. A filter such as project = ACME shown as a list with the Time Spent column, plus a subscription, gives you a regular email with the work items.

Limits: the filter lists work items, it does not total the hours. It knows nothing about a budget, so it cannot tell you that you passed 80 percent. A subscription sends on a schedule whether or not anything is wrong.

Native option 2: Automation with a scheduled rule

This is the closest native approach.

Create a rule with a Scheduled trigger (daily is plenty).
Add a Lookup work items action with JQL for the client's scope, for example project = ACME AND worklogDate >= startOfMonth().
Add a Send email or message action that goes out when the hours cross a threshold you typed into the rule.

The sum is where it gets rough. Smart values can read time spent per work item, and in a scheduled rule you can add them up across the lookup results, but check the output on a real run before you trust it: time spent on a work item covers all dates, not just the current month, so a monthly budget needs care. The threshold lives inside the rule, so every client is a copy of the rule to edit.

Limits:

Hours only. Money needs rates, and dated rates are awkward to keep inside a rule.
One rule per client or budget, with the number hard-coded.
Rule runs count towards your plan's Automation usage, and a lookup over a large project is slow.
It tells you the threshold was crossed. It does not tell you when the budget will run out at the current pace.

Native option 3: a spreadsheet

Export the worklogs (author, date, time), sum per client, compare with the budget in a column, and colour the cell when it passes 80 percent. This is honest and works, as long as someone refreshes it. In practice the export gets a week old, and the alert is a person remembering to open the sheet.

What a good warning needs

A budget with a number and a period, not a threshold buried in a rule.
Spend that is always current, with rates when the budget is money.
A pace, so "80 percent used" can be read as "11 days left" or "fine until the end of the month".
A status you can scan across all clients in one place.

Burnrate

Full disclosure: we build Burnrate. Burnrate for Jira reads the worklogs your team already logs, prices them with a dated rate card and compares them with budgets that you create per project, epic, fix version or JQL query, in money, hours or both, one-off, monthly or quarterly.

What it gives you for this problem:

A warning level per budget (80 percent by default). When usage reaches it, or the forecast says the budget will be exceeded, the budget shows as At risk. Past the limit it shows Over budget; otherwise On track.
A forecast next to the status: pace over the last 28 days, a projected total for the period and, when it falls inside the period, the day the budget runs out. How that is calculated is in the burn rate article.
All budgets in one list, so you see which clients are at risk without opening a sheet.

What it does not do: it does not email or message you when a budget turns At risk, and there is no dashboard gadget yet. You see the status when you open Burnrate. If you want a push, a team routine that opens the budget list every Monday does the job, and a native Automation rule on hours can sit next to it as a backstop.

For two or three clients with hour budgets, an Automation rule per client is fine. When there are many budgets, some in money, some resetting monthly, a status that is always current is the part worth handing over.

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

CC a whole team on every Jira Service Management ticket

Kayabyte — Sun, 01 Nov 2026 21:09:32 +0000

A common ask from support leads: "Whenever a customer opens a ticket, our account team should be copied." In email that is a CC. In Jira Service Management there is no CC field for a group, and the pieces that look like one behave differently. Here is what each does, and where the gaps are.

Request participants

Participants are people added to one request. They can view it, comment and get the same notifications as the reporter. Agents add them under People, then Request participants. Customers can do it with Share in the portal. Each person added gets an email saying so, and a participant can turn their notifications off.

The catch: a participant is one person. There is no field for a Jira group (JSDCLOUD-1268 on jira.atlassian.com asks for it), so a team of 8 is 8 entries on every request.

CC on email requests

If customers CC addresses on an email to the project's email channel, those people can be added as participants. That is real CC behaviour, but it is per email, it only covers addresses somebody typed, and it knows nothing about your groups. It does nothing for requests raised in the portal.

Organizations and customer notification settings

An organization is a named group of customers. A request shared with one is visible to its members in the portal. They get a single "Organization added" email, and later updates only if they turn notifications on for that request. So organizations answer "who can see this", not "who follows this", and they hold customers, not your internal team.

The project's customer notification settings decide which emails customers get for a request. They control what is sent to people who are already on it. They do not add anyone.

Automation

A rule on Work item created can set Request participants, so a fixed list of people can be added to every new request of a type. Depending on your Automation version this is under Edit work item or a dedicated participants action, so check what your site offers.

The limit is the one you would expect: the people are typed into the rule. When someone joins or leaves the team you edit the rule, and requests that are already open do not change. Each run also counts towards your plan's Automation usage.

When a native setup is enough

If the team is small and rarely changes, one Automation rule per request type is fine. If you only need a handful of requests followed, adding participants by hand is fine too. Neither stops being fiddly when the team changes every month.

The app route

Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management uses Jira groups instead of typed lists. From what it does today:

Rules per service project and request type (or every type if you leave it empty), each pointing at one or more Jira groups.
On a new request it adds the active members of those groups as participants, usually within a few seconds. The reporter and people already on the request are skipped.
An hourly check adds people who joined the group to matching open requests (not in a Done status category).
Removing people who left is off by default, because someone may also have been added by hand. You can switch it on.
"Sync open requests now" brings existing open requests in line, up to 1,000 per rule per run.
On any request, Actions then Add group as participants does the same for one request, using the agent's own permissions.
Limits: only active Atlassian accounts are added, and Jira Service Management decides who can be a participant, so people without customer access to the project are rejected. Portal-only customers cannot be in Jira groups, so they are not covered. It works with Jira groups, not organizations.
It runs on Atlassian (Forge) and makes no calls outside it.

Which one to use

A team should follow every request of a type, and the team changes: participants from a group.
Customers from one company should see each other's requests: an organization.
Customers who email in and CC a colleague: the email channel already handles that.

The longer version, with a FAQ, is in this guide.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Stop one person from taking ten tickets at once in Jira

Kayabyte — Sun, 01 Nov 2026 20:19:56 +0000

Nobody decides to have ten tickets in progress. It happens one at a time: a quick fix here, a review request there, a "can you just take this while you wait". By Friday one person is holding ten things, and the board looks fine.

This is about why it happens, what Jira can show you, and where the built-in tools stop.

Why it happens

Starting is free. Moving a card to In Progress costs a click, and finishing costs days.
Blocked work stays "in progress". Waiting on a reply, a deploy or a review, people start something else, and the first item never leaves the column.
The helpful people collect the most. Whoever says yes fastest ends up with the pile.
Nobody sees it. A board shows cards, not how many one person holds.

Column limits count the column, not the person

Jira's column constraints set a minimum and maximum number of work items per column and colour the header when it is exceeded. They count every work item in the column, whoever holds it, and people can still move work in. A column limit of 6 is respected with a split of 4, 1 and 1. Someone working across three boards can be under every column limit and still hold ten items.

Spot it with JQL

This finds work that is in progress and assigned:

statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee

Save it as a filter and add a Two dimensional filter statistics gadget with Assignee on one axis. Each row is one person's count across every project the filter covers. To check one person, use assignee = currentUser() AND statusCategory = "In Progress".

Assignee swimlanes on the board give a similar view for one board.

It shows the problem and stops nothing. It works when the team looks at it every day.

Automation, after the fact

A rule can trigger on a work item transitioning to your In Progress statuses, look up work items with assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress", compare {{lookupIssues.size}} with your limit, and comment or notify a lead.

The catch is timing. The rule runs after the move, so the work has already started, notifications go out, and two moves at the same moment can both slip under the count. It is a nudge. Each run also counts towards your Automation usage.

Workflow conditions and validators

To stop the move itself, the check has to run on the transition. Jira's built-in conditions and validators can look at the work item being moved: its fields, the user's permissions, sub-task status. They cannot count how many other work items the assignee already has in progress. That needs a scripted validator or an app.

Before you pick either, decide four things: across all projects or per project, what counts as starting work (To Do into In Progress yes, In Progress into In Review no), who is exempt (on-call, support), and what happens if the check cannot run. A limit that blocks people when Jira is slow does more harm than good, so let the move go ahead.

Or agree it as a team first

Pick a number, say 3, and decide what happens at the limit. In Kanban the answer is usually to help finish something instead of starting something. That alone fixes a lot. We wrote the longer version, including the flow theory, in a guide on Kanban WIP limits per person: https://kayabyte.dev/atlassian/guides/kanban-wip-limit-per-person-jira

An app that puts the check on the transition

Full disclosure: we build Personal WIP Limits, so weigh this with that in mind. Personal WIP Limits for Jira adds a workflow rule, "Personal WIP limit", that you put on the transitions that start work, in company-managed and team-managed workflows.

When the assignee is at their limit, Jira shows a message and the work item stays where it is.
One limit for everyone, counted across all projects or per project. Projects can have their own limit or be switched off, and groups can be exempt.
Moves between In Progress statuses and unassigned work are never blocked. If the app cannot check, the move goes ahead.
An admin overview shows work in progress per person against the limit.
It stores only its settings and makes no calls outside Atlassian.

Limits are a guardrail, not a guarantee, and everyone gets the same limit in this version.

If you only want visibility, the dashboard is enough. If you want the move itself to stop, the check has to sit on the transition.

I covered the column, filter and Automation options step by step in an earlier post: https://dev.to/kayabyte/how-to-set-a-wip-limit-per-person-in-jira-and-what-the-built-in-options-miss-52k5

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Burn rate and run-out date for a Jira project

Kayabyte — Sun, 01 Nov 2026 20:19:02 +0000

A budget is a number that goes down. The useful question is not how much is left, but when it will be gone. That is what burn rate and run-out date answer, and Jira has the raw material for both without giving you either.

The definitions

Burn rate: money (or hours) spent per day or per week. In Jira terms, logged time multiplied by the hourly rate of whoever logged it.
Run-out date: today plus remaining budget divided by burn rate. If 12,000 is left and the team burns 400 a day, the money lasts 30 days.
Remaining estimates: the burn rate says how fast you are spending, not how much work is left. Pricing the Remaining estimate of open work items tells you what finishing will cost, which you can hold against what is left.

The burn rate should come from recent weeks, not from the whole project. A project that crawled for two months and then got a full team has a very different pace today than its average.

For the cost side (rates, dated rate changes, budgets per epic or version), see How to see project cost and budget in Jira from worklogs. This article is about the forecast on top.

Native and manual ways

Time tracking report

Jira's time tracking report shows original estimate, remaining estimate and time spent per work item for a project or version. Good for a quick look at hours. It has no rates, no dates for the pace, and no budget to compare with.

Export plus spreadsheet

Pull the individual worklogs (author, date, time spent) through the REST API, or export work items with their time fields.
Price each worklog with a rates table.
Sum the cost of the last 28 days and divide by 28. That is your daily burn rate.
Run-out date: =TODAY() + remaining / burn_per_day.
For the estimate view: sum the Remaining estimate of open work items, multiply by an average hourly rate, add to spent.

This works, and it is the right way to learn what the numbers mean. Each step is easy; the trouble is keeping it alive.

Dashboard gadgets

A Filter results gadget can list time spent and remaining estimate per work item, but the built-in gadgets count work items rather than total hours, so totals still mean an export. Either way it is hours, not money, and the gadgets do not know your budget or your pace.

Where it stops working

The sheet is stale as soon as someone logs time or moves work between epics.
A 28-day window needs a daily recompute. Nobody does that by hand.
The first week of a month or project gives a pace that swings wildly. You need a rule for when to trust it.
A run-out date after the budget period ends is not interesting. A formula happily prints it anyway.
Rates are sensitive, and the people who should see a run-out date are rarely the people who should see what each colleague costs.

Burnrate

Full disclosure: we build Burnrate. Burnrate for Jira reads the worklogs your team already logs, prices them with a dated rate card and compares them with a budget. This is how its forecast works, taken from how we built it:

Pace is the average daily spend over the last 28 days, or over the days since the period started if that is shorter.
Run-out date is the money (or hours) left divided by that pace. If the budget has both an amount and hours, the earlier of the two wins.
It only shows a date that falls inside the budget's period. If the pace would not use the budget up in time, you see the projected total at the end of the period instead.
It waits until there are enough days to forecast from: 7 days of pace, or half the period for budgets shorter than two weeks.
Estimate at completion is spent so far plus the Remaining estimates of open work, priced at the scope's average cost per hour. It is a separate figure from the run-out date, so you can see both views, and for one-off budgets a budget is marked at risk if either points over it.
A budget is flagged At risk when usage passes your warning threshold or the forecast goes over the budget.

It does not email you about it, and it has no dashboard gadget yet. You see the forecast in the budget list and on each budget.

For one project and a monthly look, the spreadsheet above is enough. When several budgets run at once and you want the run-out date to be current when you open the page, that is the part worth handing over.

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Jira Service Management: keeping request participants in sync with a group (joiners and leavers)

Kayabyte — Sun, 01 Nov 2026 20:08:31 +0000

Adding a team to a request once is the easy part. The part that bites is next quarter: somebody joins finance, somebody leaves, and the requests already open still show last quarter's team. This is about keeping request participants in step with a group over time, and what Jira Service Management gives you for it. (If you only need the one-off "add a team to new requests" setup, I covered that in this article.)

Participants and organizations are different things

Request participants are people on one request. They get its notifications and can comment in the portal. There is no field for a group, so a team of 12 is 12 entries.
Organizations are lists of customers kept in Jira Service Management. Sharing a request with one makes it visible to the members. They get one "Organization added" email, and later updates only if they turn notifications on for that request.
Neither is a Jira group. An organization is a second list that has to be maintained next to the group you already have.

So for "this team follows these requests, and the team changes", participants are the right field and organizations are not a substitute.

What happens when group membership changes

Nothing, natively. Jira groups and request participants are not linked. Add someone to a group and no existing request gains a participant. Remove someone and they stay on every request they were already on. Whatever you build has to do the syncing itself.

Option 1: Automation

A rule on Work item created, with a request type condition, can set the Request participants field. Depending on your Automation version you will find this under Edit work item, or as a dedicated action for request participants. Check what your site offers, since I have not confirmed the exact action name on every plan.

Limits for the joiners and leavers problem:

A rule has no built-in "members of this group" list. The people are typed into the rule, so every team change means editing it.
It runs on creation. Requests that are already open are not touched when you edit the rule.
You can add a second rule on a schedule that searches open requests and edits each one. That works, but you have to write the add part, the remove part, and the people list yourself.
Smart values give you the reporter and the fields on the request. I would not rely on them to expand a group into accounts. Test that on a throwaway request before building on it.
Every run counts towards your plan's Automation usage.

Option 2: the REST API

This is the flexible route, and the pieces are small:

Read the group: GET /rest/api/3/group/member?groupId=...&includeInactiveUsers=false, paged.
Find open requests: JQL such as project = SD AND statusCategory != Done AND "Request Type" in ("Invoice question").
Read current participants: GET /rest/servicedeskapi/request/{issueIdOrKey}/participant.
Add the missing ones: POST /rest/servicedeskapi/request/{issueIdOrKey}/participant with a body of {"accountIds": [...]}.
Remove leavers: DELETE on the same path with the same body shape.

Things that will trip you up:

One person who cannot be a participant (no customer access to that service project, for example) can make the whole POST fail with a 400. Retry the batch one account at a time.
Rate limits happen on long runs. Honour Retry-After and make the job safe to run again.
To find joiners and leavers you must keep the last-seen member list somewhere and compare it with the current one. Without that you cannot tell a leaver from someone who was added by hand.
Decide about leavers on purpose. A person removed from the group might also have been added to a request manually, and a blanket cleanup would drop them.
Someone may be covered by two rules for the same request type. Removing them because they left one group would be wrong.

It is a perfectly good small script, and it needs somewhere to run and be maintained.

Option 3: an app that does the sync

Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management is the script above, packaged as a Forge app. From what it does today:

Rules per service project and request type, each pointing at one or more Jira groups. New matching requests get the groups' active members as participants.
An hourly sync looks at open requests (not in a Done status category) that match a rule and adds people who joined the group since the last run.
Removing people who left is opt-in, because they may have been added by hand. Someone who left one rule's groups but is still covered by another rule for that request type stays on.
A "Sync open requests now" button runs it on demand, and a manual run re-adds every current member.
If a lookup fails or is rate limited, the rule keeps its old snapshot, so the next run tries the same joiners and leavers again. It does not treat a failed group lookup as an empty group.
People JSM will not accept as participants are counted as "could not be added", and one such person does not fail the whole batch.
A rule covers up to 1,000 open requests per run.
An agent can also add any group to a single request from the work item's actions menu.
It works with Jira groups, not organizations, and it does not cover portal-only customers, because JSM does not allow them in groups.
It stores only its settings and member snapshots, makes no calls outside Atlassian, and runs as its own Forge app, so it does not use your Automation runs.

If your team rarely changes, an Automation rule is enough. If it changes every month and open requests matter, either write the scheduled script with the checks above or use an app. The thing to avoid is a hand-edited list that nobody owns.

For the difference between organizations and participants in more depth, see this guide.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How to notify a whole team when a new page is added to a Confluence space

Kayabyte — Sun, 01 Nov 2026 19:08:50 +0000

A team lead publishes a new page in the team's Confluence space and then wonders whether anyone saw it. Confluence Cloud has several ways to tell people, but none of them is a single switch that says "notify this team about every new page". Here are the native options with their limits, and one app at the end.

Option 1: everyone watches the space

Watching a space covers all its pages and blog posts, so a watcher is told about new pages. Each person selects Watch on the space for themselves. Watching is per user account, so a group of 30 people is 30 separate watches.

The catch is how the notification arrives. Open your profile picture, then Settings, then Email:

Daily Digest collects recent activity into one email a day. On a new account it includes new pages and live docs.
Content I'm watching decides what is emailed in real time. On a new account only Comments, New blog posts and New whiteboards are on. New pages and live docs is off.

So by default a watcher hears about a new page the next day, in the digest. For real-time emails each person has to switch on New pages and live docs under Content I'm watching. It is a personal setting, so you can't set it for the team.

Option 2: @mention the team or the people in the page

Mentioning someone in a page notifies that person, and it works well for one announcement. The limits: it is manual, it depends on the author remembering, and the mentioned person must be able to see the page. It also does nothing for the next page.

Option 3: Automation for Confluence

Automation for Confluence can run a rule when a page is created in a space. As far as I could verify, the actions include sending an email and posting to Slack or Microsoft Teams, which covers "tell the team about new pages". Check two things in your own site before you rely on it: which recipients the email action accepts (a list of people, or a group), and that the Slack or Teams integration is connected for your site. I did not find an action that makes a group watch a space, so rules are for announcing, not for watching.

The upside is that the message goes out in real time and lands where the team already looks (a channel). The downside is that someone owns the rule and the recipient list, and people who join the team later are only included if the list follows the group.

Option 4: an admin adds the watches with the REST API

An admin can add a watch for another person with the REST API, one account at a time: POST /wiki/rest/api/user/watch/space/{spaceKey}?accountId={accountId}, with the header X-Atlassian-Token: no-check, as a Confluence Administrator or a Space Administrator of the space. A script can loop over a group's members. It is a snapshot, though: joiners are missed, leavers keep watching. I wrote the whole script and its limits in How to make a Confluence group watch a space, so I won't repeat it here.

Option 5: an app that keeps the group watching

Full disclosure: we build Group Watchers, so weigh this accordingly. Group Watchers: Auto-Watch Spaces & Pages for Confluence maps one or more groups to a space or a single page and keeps the members watching:

It runs right after you change a rule and then every hour.
Joiners start watching. For leavers it removes only the watches it added, and you can switch removal off.
People who unwatch are not added back, and watches people already had are never touched.
It runs on Atlassian's Forge platform and sends no data outside Atlassian.

What it does not do: it doesn't send its own notifications and doesn't change anyone's email settings. A watcher gets Confluence's normal notifications, based on their own settings. So the digest point from Option 1 still applies, and new pages arrive in real time only for people who switched on New pages and live docs.

Which one to pick

One announcement: @mention, or post in the team channel.
Real-time heads-up for every new page, in chat or email: an Automation rule on page created.
Team members should get Confluence's own notifications, and the team changes often: keep the group watching, with a script you maintain or an app.

These also combine well: watching for the personal feed, and an Automation rule for the channel.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How to see project cost and budget in Jira from worklogs

Kayabyte — Sun, 01 Nov 2026 18:19:12 +0000

Your team already logs time in Jira. Finance asks what the project has cost so far and whether the budget will last. Jira holds the hours but not the money. Here is how to get from one to the other with the built-in tools, and where that stops.

What Jira gives you

Worklogs: who logged how much time, on which work item, on which day.
Time tracking fields: Original estimate, Remaining estimate and Time spent on each work item.
JQL to find the work items in a project, epic or version, and CSV export with their time fields.

Everything is in hours. Jira has no hourly rates and no budget with an amount and a period.

Option 1: export and a spreadsheet

Exporting work items gives you Time spent per work item, but not per person or per day. For a real cost you need the individual worklogs: author, date and time spent.

Pull the worklogs with the REST API: /rest/api/3/issue/{key}/worklog per work item, or /rest/api/3/worklog/updated plus /rest/api/3/worklog/list for everything changed since a date.
Keep a rates table with one row per person or role, an hourly rate and a start date. When a rate changes, add a row instead of editing the old one.
Price each worklog with the rate that applied on its own date: hours times rate. If you only keep the current rate, every rate change silently re-prices past work.
Group the cost by project, epic or fix version. For epics and versions, include the time on child work items and sub-tasks.
Compare with the budget: spent so far, remaining, share used.

Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#jira-epic-cost

Where the spreadsheet breaks

It goes stale. Worklogs are added, edited and deleted every day, and work moves between epics and versions. A monthly export is out of date within days.
Forecasting is manual. "Will the money last?" needs a pace, a run-out date and the remaining estimates of open work priced at your average rate.
Cost and billing differ. What an hour costs you and what you bill the client are different rates, so you need two tables.
Rates are sensitive. Most people who should see whether a budget is on track should not see what each person costs, so the sheet ends up shared with very few people.

Option 2: Automation

A scheduled rule can look up the work items in an epic or project and message someone when their time spent passes a threshold you typed in. That is a rough check of hours against an hour budget. For money you still need a rates table somewhere, and dated rates are awkward to keep inside a rule. Rule runs also count towards your plan's Automation usage.

Rules that keep the numbers trustworthy

Never change a past rate. Add a new one with a start date.
Decide once what a budget covers (a project, an epic and its children, a version or a JQL query) and whether it is one-off or resets every month or quarter.
Keep non-billable work out with a label, and apply it to the work under it too.

Option 3: an app that reads the worklogs

Full disclosure: we build Burnrate, so weigh this one with that in mind. Burnrate for Jira reads the worklogs your team already logs and keeps the numbers current.

A rate card with dated cost and billing rates for a default rate, roles and people. A new rate never changes the cost of past work.
Budgets in money or hours for projects, epics, fix versions or any JQL query, one-off, monthly or quarterly.
Pace, run-out date, projected spend and an estimate at completion from remaining estimates.
A Cost panel on every work item and epic, and reports by project, epic, person or month with CSV export.
Two Jira permissions decide who manages rates and who only sees budgets.

For one small project and a monthly report, the spreadsheet is fine. When several budgets run at once and rates change, keeping it current by hand is the part that stops working.

More detail in the guide: https://kayabyte.dev/atlassian/guides/jira-project-cost-from-worklogs

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How to set a WIP limit per person in Jira (and what the built-in options miss)

Kayabyte — Sun, 01 Nov 2026 18:18:39 +0000

"Nobody should have more than three things in progress." It sounds simple, and Jira makes it surprisingly hard. The limits Jira gives you are on columns, not on people. Here is what you can do with the built-in tools, step by step, and where each one stops.

Column limits count the column, not the person

On a board, under Columns, you can set a minimum and maximum number of work items per column. Jira colours the column when it goes over.

The limit counts every work item in the column, whoever it is assigned to. One person can hold most of a column and the limit still looks fine.
It is a warning. People can still move work into a full column.
It counts one board. Someone who works across three teams' boards can be under every column limit and still have ten things in progress.

Column limits help a team see a bottleneck. They do not give anyone a personal limit.

Option 1: a filter and a dashboard

You can at least see who is overloaded.

Save a filter with this JQL:

statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee

Add a Filter results or Two dimensional filter statistics gadget to a dashboard, using that filter, with Assignee on one axis.

Each person's count is the number of work items they have in progress. This shows the problem. Nobody is stopped, and somebody has to look at the dashboard.

Option 2: Jira Automation

Automation can warn when someone goes over.

Trigger: Work item transitioned, to your In Progress statuses.
Action: Lookup work items with JQL like assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress".
Condition: {{lookupIssues.size}} greater than your limit.
Action: comment, notify the team lead, or transition the work item back.

The gap: the rule runs after the move. The work has already started, people get notifications about a move that is then undone, and the count can be off when two moves happen at the same moment. It is a nudge, not a limit. Each run also counts towards your plan's Automation usage.

Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#jira-wip-per-person

Option 3: stop the move itself

To block a work item from starting when its assignee is at their limit, the check has to run on the transition, before the move happens. Jira's built-in validators cannot count how many work items someone already has in progress, so this takes a scripted validator or an app.

Whichever route you take, decide these first:

Across all projects, or per project? One limit for everything a person does, or one per project for people who split their time on purpose.
What counts as starting work? To Do into In Progress should count. In Progress into In Review should not.
Who is exempt? On-call and support rotations often need to pick up urgent work regardless.
What happens if the check fails? A limit that blocks people when Jira is slow does more harm than good. Let the move go ahead.

Option 4: an app that adds the workflow rule

Full disclosure: we build Personal WIP Limits, so weigh this one with that in mind. Personal WIP Limits for Jira adds a workflow rule you put on the transitions that start work, in company-managed and team-managed workflows.

When the assignee is at their limit, Jira shows a message such as "Alex has reached the limit of 3 work items in progress" and the work item stays where it is.
Count across all projects or per project, give projects their own limit or switch them off, and exempt groups.
Moves between In Progress statuses and unassigned work are never blocked. If the app cannot check, the move goes ahead.
It stores only its settings and makes no calls outside Atlassian.

If you only want visibility, the dashboard from Option 1 is enough. If you want a limit that actually stops the move, the check has to sit on the transition, and that is the part worth an app or a script.

More detail, including the flow-theory side, in the guide: https://kayabyte.dev/atlassian/guides/jira-wip-limit-per-person

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Adding a whole team as request participants in Jira Service Management

Kayabyte — Sun, 01 Nov 2026 18:00:35 +0000

A request comes in and a whole team needs to follow it: finance on every invoice question, facilities on every move request. In Jira Service Management that is more awkward than it should be, because request participants are individual people. There is no field for a group. Here is what you can do with the built-in options, and where each one stops.

How request participants work

Request participants is a field on service requests. Everyone in it gets the request's customer notifications and can see and comment on it in the portal.
It holds people, not groups. Adding a group means adding each member by hand.
Only people who may raise requests in that service project can be participants. On sites where customers need explicit access, group members without it are rejected.

Atlassian's request for group participants, JSDCLOUD-1268, has collected hundreds of votes over the years and has not been built.

Option 1: organizations

In the service project, go to Customers and create an organization, or use an existing one.
Add the people to it.
Customers in the organization can share requests with it, and agents can share a request with an organization.

The catch: sharing with an organization makes the request visible to its members, but it does not make them participants. Members get one "Organization added" email, and later updates only if they turn notifications on for that request. Organizations are also separate from Jira groups, so somebody has to keep both lists in step.

Option 2: Jira Automation

A rule can set the Request participants field when a request is created.

Trigger: Work item created, with a condition on the request type.
Action: Edit work item, and set Request participants to the people who should follow it.

That works for a fixed list of people. Automation has no simple built-in way to turn a Jira group into its current members, so the list lives inside the rule and someone updates it when people join or leave. Requests that are already open do not change when the list does. And every rule run counts towards your site's monthly Automation usage, which is limited by plan.

If you are comfortable with the REST API, there is a more flexible route: the service desk API can add participants to a request with one call listing several account IDs, and you can read a group's members with the group/member endpoint. Wire that into a scheduled rule or a script and you get something close to group behaviour. It is also more moving parts to maintain, and it won't remove leavers unless you write that part too.

Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#jsm-group-participants

Option 3: ask the requester

Requesters can add participants from the portal. Fine for one-off requests, unreliable for "this team must always be on it".

Decide these before you automate anything

Which requests? Usually a few request types per project, not everything.
New requests only, or open ones too? When someone joins the team, should they be added to requests that are already open?
What about leavers? Come off open requests, or stay until it is closed?

Option 4: an app that works from Jira groups

Full disclosure: we build Group Participants, so take this one with that in mind. Group Participants for Jira Service Management works with the Jira groups you already have:

Rules per service project and request type: new requests get everyone in the chosen groups as participants.
An agent action adds any group to a request from the work item's actions menu.
An hourly sync adds people who join a group to matching open requests. Removing people who leave is optional, and someone still covered by another rule stays on.
It stores only its settings and member snapshots, and makes no calls outside Atlassian.
It runs as its own Forge app, so it does not use your Automation rule runs.

Other Marketplace apps do the same thing, some of them cheaper. I compared a few here: https://kayabyte.dev/atlassian/guides/jsm-group-request-participants-apps-compared

For a fixed team and a couple of request types, an Automation rule is probably all you need. Once the team changes regularly, keeping a hand-written list current is the part that starts to hurt.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How to make a Confluence group watch a space (and keep it updated when people join)

Kayabyte — Sun, 01 Nov 2026 17:53:36 +0000

A common ask from team leads: "everyone on the team should get updates from our Confluence space." In Confluence Cloud that turns out to be harder than it sounds, because watching is something each person does for themselves. Here is what actually works, and where each option stops.

What the built-in behaviour is

Each person selects Watch on a page or a space. Watching a space covers all its pages and blog posts.
Only user accounts can watch. There is no way to add a group as a watcher, so a group of 40 people is 40 separate watches.
People see what they watch under Notifications, Watching, and can unwatch whenever they like.

So the native options are: ask everyone to click Watch (works for five people, not for fifty), or have an admin set the watches for them.

Option 1: an admin sets the watches with the REST API

Confluence's REST API can create a watch for another person, one at a time:

Space: POST /wiki/rest/api/user/watch/space/{spaceKey}?accountId={accountId}
Page: POST /wiki/rest/api/user/watch/content/{pageId}?accountId={accountId}

You need the header X-Atlassian-Token: no-check, and the caller must be a Confluence Administrator, or a Space Administrator of that space. Anyone else can only add a watch for themselves. A watch never grants access, so members who can't see the space are skipped.

Here is a one-time script that adds every member of one group to one space. It needs an API token for your own account, curl and jq:

SITE="https://your-site.atlassian.net"
AUTH="you@example.com:your-api-token"
SPACE="TEAM"          # the space key
GROUP="developers"    # the group name

# 1. Look up the group's ID
GROUP_ID=$(curl -s -u "$AUTH" "$SITE/wiki/rest/api/group/picker?query=$GROUP" \
  | jq -r --arg n "$GROUP" '.results[] | select(.name == $n) | .id')

# 2. Read the members, 200 at a time, and add a watch for each
start=0
while :; do
  page=$(curl -s -u "$AUTH" "$SITE/wiki/rest/api/group/$GROUP_ID/membersByGroupId?start=$start&limit=200")
  for id in $(echo "$page" | jq -r '.results[] | select((.accountType // "atlassian") == "atlassian") | .accountId'); do
    curl -s -o /dev/null -w "%{http_code} $id\n" -u "$AUTH" -X POST \
      -H "X-Atlassian-Token: no-check" \
      "$SITE/wiki/rest/api/user/watch/space/$SPACE?accountId=$id"
  done
  [ "$(echo "$page" | jq -r '._links.next // empty')" = "" ] && break
  start=$((start + $(echo "$page" | jq '.results | length')))
done

A 204 means the watch was added. For one page, use the page endpoint with the page ID from the URL.

Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#confluence-group-watch

Where the script stops

It is a snapshot. Fine for a one-time rollout, but groups change:

Joiners are not added until you run it again.
Leavers keep watching, and keep getting emails about a space that is not theirs any more.
People who unwatched on purpose get added back on the next run, and usually respond by filtering the emails.
Watches people set up themselves look identical to the ones you added, so a cleanup script can't tell which ones it may remove.

You can put the script on a schedule, but then you also need a record of which watches you added, who opted out and who already watched before. That record is the real work.

Option 2: Automation for Confluence

I looked for a way to do this with Automation for Confluence rules and did not find a built-in "add watcher" action for a group's members, so I would not count on it. You can have a rule send a notification or post when a page is created in a space, which covers "tell the team about new pages" but not "make the team watchers". If you know of a way I missed, I'd like to hear it.

If watchers say they get no email

Before changing anything, check the email defaults. New pages and page edits in watched content go into the daily digest by default, while comments are emailed straight away. Each person can change it under their profile picture, Settings, Email. Updates also show under Notifications, Watching in Confluence itself.

Option 3: an app that keeps the watches in sync

It runs right after you change a rule and then every hour.
Joiners start watching. For leavers it removes only the watches it added, and you can switch removal off.
People who unwatch are not added back, and watches people already had are never touched.
It runs on Atlassian's Forge platform and sends no data outside Atlassian.

There are other Marketplace apps for this too, one of them free. I put a comparison on our site: https://kayabyte.dev/atlassian/guides/confluence-group-watch-apps-compared

If your group is small and stable, the script above is enough. The app earns its place when people move around often and you don't want to own the bookkeeping.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How to set up wholesale prices for B2B customers in your Wix store

Kayabyte — Sun, 01 Nov 2026 07:02:30 +0000

Wix Stores has one price per product and no wholesale mode. Wix's own suggestion for trade prices is a members-only page with duplicated products at wholesale prices. That works for a small range, and it gets heavy as the range grows. Below is the built-in setup first, what it can't do, and then an app that applies a group price to the products you already have.

What does Wix offer for wholesale prices?

Wix describes the workaround in Creating restricted store pages:

Duplicate each product you want to sell wholesale, and give the copy its wholesale price.
Put the copies in a new category, for example "Wholesale", and create a store page that shows only that category.
In the editor, open Pages & Menu, open the page's settings, and under Permissions choose Site members.
In your dashboard, go to Signup & Login Security and choose Only people I manually approve, so you decide who becomes a wholesale member.
Hide the wholesale page and its products from search engines.

Things to know before you build on it:

The wholesale products are separate copies. Prices, photos, descriptions and stock have to be kept in step in two places.
Retail and wholesale shoppers browse different pages, so a trade customer who forgets to use the wholesale page pays the retail price.
Wix points larger B2B shops to a dedicated wholesale app.

Can I use a discount or coupon instead?

Wix Stores has coupons and automatic discounts under Marketing. They give a percentage or amount off, with conditions such as a minimum order or chosen products.

Coupons can't be limited to certain customers. Wix's limiting coupon usage options cover the products, an end date, the total number of uses and one use per customer, so a plain coupon code can be shared or guessed. Automatic discounts can be limited: Wix's automatic discounts help describes an eligibility setting where you choose a specific contact with a label. So a label-based percentage discount is possible without an app. It is one discount per rule, and it has no groups with different prices, no fixed price per product and no minimum order tied to a group, which is where the section below starts.

Where the built-in options stop

Several trade groups managed in one place, on the same products retail customers buy, with no duplicates.
Different groups with different discounts, such as 20% for resellers and 30% for distributors.
A discount for one collection, such as 40% off the whole accessories range for trade.
A fixed trade price for one product, such as 8.50 each, whatever the retail price.
A minimum order before trade prices apply, such as a cart of at least 300.

Mark your wholesale customers with a contact label

Whatever you use, you first need a way to tell Wix who is wholesale. Contact labels are the simplest. Wix explains them in Creating and using contact labels:

In your dashboard, go to Contacts.
Click the More Actions icon, then Labels, then + Add Label. Name it, for example, "Wholesale", and click Done.
To label a customer, open the contact, click Labels, then + Add Label, choose "Wholesale" and click Add.

A customer has to be a site member to be recognised before checkout, so ask trade customers to sign up and log in, and approve them yourself.

An app that applies group prices

Full disclosure: I built Wholesale Prices & B2B Groups. You create a group, give it one or more contact labels and choose its pricing: a percentage off the whole store, off chosen collections or products, or a fixed price per product, with an optional minimum order subtotal. A logged-in member whose contact has the label then pays the group price in the cart and at checkout, and sees it next to the regular price on the product page. Everyone else sees your normal prices, and you keep one set of products.

What to know before you rely on it:

The buyer must be logged in as a site member whose contact has the label. A trade customer who isn't logged in pays the retail price.
The price line shows on the product page only, not in product grids or category pages. The cart and checkout always show the discount.
Only one automatic discount applies per order, and the best price wins. Overlapping groups or a store-wide automatic sale don't add up.
If the app can't check a customer in time, the customer pays the normal price and the sale goes ahead, so a slow check never blocks an order.
Coupon codes a customer types in come off on top of the group price. We checked this in a live cart: the group discount and the coupon both showed, and the coupon was taken off the already reduced price. Only automatic discounts compete with the group price.
The free plan has 1 group with one store-wide percentage. Collection and product prices, fixed prices, unlimited groups, a minimum order and a "log in to see your price" line for guests are on the paid plan.
The product page price line needs a site built in the Wix Editor.

It's on the Wix App Market.

FAQ

Can I show wholesale prices only to approved customers?
With the built-in setup, put wholesale products on a members-only page and approve members yourself. With the app, the group price shows only to logged-in members whose contact has the label; guests see the normal price.

Do I need duplicate products for wholesale?
Not with the app. Group prices apply to the products you already sell. With the built-in setup, yes.

Does the group price show in product lists?
No. The app shows the price line on the product page, and the cart and checkout show the discount. There is no slot for it in product grids.

Can a customer be in two groups?
Yes, but only one automatic discount applies per order, and the best price wins. A coupon code the customer types in comes off on top.

Do I need a paid plan?
One group with a single store-wide percentage works on the free plan. Pricing per collection or product, fixed prices, more groups and a minimum order need the paid plan, which has a 14-day free trial.

Wix pages last checked: 17 October 2026. App details: 31 October 2026.

Related guides

Wix wholesale minimum order: different rules for wholesale and retail
Minimum order and quantity limits on Wix: every option compared
Wix Stores minimum order quantity, per product or category
How to let customers choose a pickup time in Wix Stores (for wholesale bakeries, florists and food shops that collect orders by time slot)