rss.livelink.threads-in-node

Your Approver Is Away. The Approval Doesn't Have to Wait.

Shreyas_Quietmill — Sun, 23 Aug 2026 21:25:42 GMT

Disclosure: I build Approval Nudge at Quietmill, the app discussed below.

Someone books two weeks off. Their out-of-office turns on. Jira keeps waiting for that same person to approve a laptop, an access request or a change.

Nothing is technically broken. Nothing moves either. The requester waits, the service desk chases, and sooner or later an admin edits the Approvers field by hand—then has to remember to undo it when the person returns.

Version 3.13 added two connected Advanced features: planned cover while an approver is away, and a ledger that records what happened afterwards.

Version 3.14 made the admin screens easier to live with: tabbed project settings, a clearer Approvals Overview and ledger, consistent dates and better people pickers.

Set the cover before the leave starts

Add the person who is going away, their first and last day away, and the person covering for them. While that absence is active, the next scan adds the stand-in to any approval still waiting for the absent person. It does not wait for the normal reminder threshold; the leave is already known.

Schedule the dates once. Approval Nudge checks them during the scans it already runs.

The important word is adds. Approval Nudge does not replace the original approver or transfer their identity, authority or decision. The stand-in joins the request as another approver, and the original approver can still respond. If anyone approves or declines, the app leaves the approval alone.

When cover is added, the request gets an internal note naming both people and the last day of the absence. The Jira Approvals panel shows both approvers, so an agent can see the handoff without opening another screen.

The stand-in is additional. The original approver remains on the request.

It includes the people who actually approve

This matters on migrated sites and on service desks where customers do the approving. Those approvers may be portal customers rather than licensed agents, and JSM customer accounts do not appear in Atlassian's standard user picker for apps. A leave feature that cannot find them would work in a demo and fail on the real service desk.

Approval Nudge therefore searches both Jira users and JSM customers when an admin chooses who is away and who covers. It is the practical version of the temporary-approver request in JSDCLOUD-7867, which was opened in 2018 and currently has 249 votes.

Answer the audit question without Jira archaeology

Keeping an approval moving solves today. The approvals ledger is for the question that arrives weeks or months later: Who was asked? Who answered? When did it happen? What did the app do in between?

Without one record, the answer is scattered across issue history, internal comments and app activity. The ledger puts the approval lifecycle and the app's actions in time order: approval started, approved or declined, reminders, resent Jira approval emails, escalations and stand-ins.

Filter by project and date, follow a request key back into Jira, or export the rows as CSV. A Jira administrator chooses whether entries are kept for 90 days, 180 days or one year; older entries are removed automatically during the daily cleanup.

One place to see what Jira did, what Approval Nudge did, and when.

That record also stays where the approval lives. Approval Nudge has no vendor servers and no data egress. It runs on Atlassian's infrastructure, so the approval history remains inside your Atlassian site rather than being copied into a separate vendor database.

The boundaries, before you test it

Planned cover needs individual people in Jira's Approvers field. Group-based steps and team-managed approvals do not give the app that list, so Approval Nudge leaves those approvals alone.

The ledger is not retroactive. It starts recording when Approval Nudge next scans an approval after the upgrade; it cannot reconstruct decisions that happened before the ledger was watching.

Both features are available in the Advanced edition. Standard reminders, resends and escalation continue as before.

Where this fits in the series

The complete guide to JSM approval workflows maps the approval journey from workflow setup to reporting. The previous episode, The Approvals Nobody Should Be Reminded About, covers requests your scans should leave alone. This release handles the opposite case: a real approval still needs an answer, but the person Jira is waiting for is away.

How does your service desk handle approver leave today—manual edits, a rota, shared accounts, or an admin who remembers everything? I would genuinely like to hear what works and where it breaks. Those answers are how features like these get built.

Full Contact Numbers List for OpsGenie Alerting

Michael Strickler — Sun, 23 Aug 2026 11:34:18 GMT

I think we have counted at least like 30 different phone numbers (I feel pretty confident there are more!) that OpsGenie uses when enacting its notifications protocols.

We are finding that a lot of these numbers are getting blocked by our spam filters, which can not be disabled.

Three questions:

Does OpsGenie relegate a specific section of numbers to each Company/Team/Member when notifying?
Would it be possible to do this if not, so they can be added to an exceptions list?
And ultimately, is it possible to get a full list of the numbers we could receive calls/messages from?

Unable to delete my Atlassian account despite having no active billing

Roberto Falcone — Sun, 23 Aug 2026 08:23:19 GMT

Hello Atlassian Support,

I'm contacting you because I'm trying to delete my Atlassian account after briefly trying Trello, but the process seems to make it unnecessarily difficult to do so.

Every time I attempt to delete my account, I receive the following message:

You can't delete your account
Your account can't be deleted because:
User is last billing admin of a transaction account that has one or more active entitlements.

I then tried using the GDPR self-service deletion procedure, but this simply brings me back to the exact same message.

What makes this particularly confusing is that I have checked my account and I have no active billing, subscriptions, or paid plans connected to Trello or any other Atlassian app. I therefore have no idea what "active entitlement" is supposedly preventing me from deleting my account.

I find this quite frustrating. I no longer wish to use Trello or any other Atlassian service, I have no intention of maintaining any active subscription or entitlement, and I simply want my Atlassian account and associated personal data to be deleted.

If there is some hidden or residual entitlement preventing deletion, please remove it or provide me with clear and specific instructions for doing so. At the moment, the process feels circular: I am told I cannot delete my account because of something I cannot see or manage, while the GDPR deletion procedure leads me straight back to the same error.

Please confirm how I can permanently delete my account, or process the deletion on my behalf. Thank you.

Private view

Gal Fatal — Sun, 23 Aug 2026 08:19:29 GMT

Hi,

I have some people work on JPD and would like to create a private view.

Seems it's not possible.

Is it possible with premium license?

The Evolution of Extensibility: What ScriptRunner’s Migration to Atlassian Forge Means?

Viswanathan Ramachandran — Sun, 23 Aug 2026 07:29:05 GMT

ScriptRunner is moving to Atlassian Forge: https://www.scriptrunnerhq.com/products/moving-to-atlassian-forge

If you’ve spent any time in the Atlassian ecosystem, you know ScriptRunner has long been the gold standard. It’s the "swiss army knife" we reach for when out-of-the-box features hit a wall.

Full disclosure: I’m not necessarily comfortable with this move, nor am I fully cheering it on just yet. I love ScriptRunner as a standalone, battle-tested product that already solves most of my requirements. But if this is the direction the ecosystem is heading, pragmatism wins and I shall adapt.

When a powerhouse app shifts its cloud foundation to Atlassian Forge Remote, it signals a fundamental change in how enterprise software will be customised moving forward.

Here is my strategic take on what this shift actually means for us in the trenches:

1. Security & Governance Catch Up to Raw Power Historically, using deep cloud customisations meant having tough conversations with Infosec about third-party hosting and data egress. By anchoring to Forge, ScriptRunner inherits Atlassian’s native data boundary controls. It trades a bit of traditional flexibility for enterprise-grade compliance—a trade-off many security teams are demanding.

2. Tighter UI, Lower Latency Operating natively within Atlassian’s framework brings customisation closer to the core UI. For end-users, the transition between native Jira and custom business logic becomes virtually invisible.

3. The Ultimate Stress Test for Forge This isn't just a ScriptRunner update; it’s a trial by fire for Atlassian. Forcing one of the most complex, code-heavy apps in the marketplace onto Forge will push Atlassian to mature its serverless platform capabilities far faster than before.

The Bottom Line Adaptation is part of the job. In the near term, there will inevitably be a learning curve and friction as complex scripting models adjust to serverless environments. But long term, this collaboration sets a new baseline where power and governance have to coexist.

Over to the community:

How are you feeling about this move? Are you ready to adapt to the governance benefits, or are you concerned about serverless limits on complex scripts?
How is your team balancing custom code vs. native Cloud automation right now?

Let’s discuss and I like to see the engagement

Would one Jira Service Management admin test a read-only request-form audit app?

Paul — Sun, 23 Aug 2026 06:01:29 GMT

Hello! I’m looking for one Jira Service Management Cloud administrator to test a small private-beta Forge app called Request Form Auditor.

The app compares the customer-facing fields across request types in a Jira Service Management project and produces a copy-ready consistency report.

The app is read-only. It requests permission only to:

View service desks
View request types and request-form field metadata

It cannot edit forms, delete request types, inspect tickets, read comments, or access attachments.

An ideal tester:

Administers an Atlassian Cloud site with Jira Service Management
Has a test or non-sensitive project with at least two portal request types
Can spend approximately 10–15 minutes installing the app, running one scan, and sharing usability feedback

The private installation link will not be posted publicly. If you’re interested, please reply here, and I’ll contact you privately with the installation steps and privacy information.

Thank you!

Can't Request Support to Regain Admin Rights to my Own Domain

2T Secuurity — Sun, 23 Aug 2026 00:58:44 GMT

I'm feeling extremely stuck. I just tried to login to my Jira account for the first time in a while and realized I don't have admin permissions on my site. I'm the only user on the site and own the domain registered...this has been a site only for my own use.

So, I went to the support page to get help and now the support page doesn't recognize my Cloud URL...so, am I just stuck at this point? I don't know where else to go.

Ask Alfred: How Claude Fable 5 Helped Me Build a Rovo Agent That Actually Knows Our Jira

Ben Spillane — Sun, 23 Aug 2026 00:45:24 GMT

The problem with "why did my issue do that?"

Picture this: a team member transitions an issue to "In Review." Three things happen automatically. A sub-task gets created. An email goes out. A linked issue changes status. Nobody told them any of this would happen — there's no tooltip, no notification, no breadcrumb. Just... consequences.

They ask the only person who can explain it: the platform admin. He opens the rule tree, mentally decodes customfield_10666 into "Change Object Type," resolves status 10461 to "Active" walks three nested conditional branches, and ten minutes later has an answer.

Multiply that by 61 active automation rules, 242 conditional branches, and a team that uses Jira every day — and you've got a quiet but real support burden sitting on one person's shoulders.

That's the problem Ask Alfred was built to solve.

What “Ask Alfred” actually is

Ask Alfred is a Rovo Agent. Its entire knowledge base is a plain-English translation of the instance's own automation export — not a hand-written FAQ, not a general "how Jira automation works" document. Every active rule, every condition, every action, rendered into readable prose by a Python script and fed to the agent as its source of truth.

Ask it "why did my issue just close?" and it walks the rule tree for you. Ask it "what automations run when I create an issue in this project?" and it lists them. Ask it "why didn't the sub-task get created?" and it walks each gate until it finds the one that was likely false.

The key word there is this instance. Not how Jira automation generally works — how your automation is actually configured, right now.

The blueprint

The pipeline has three stages that feed the Rovo agent:

Seven inputs feed the script: the automation rules export from Jira, plus six reference exports that resolve the raw IDs the rules are full of — project IDs, user account IDs, custom field IDs, issue type IDs, link type IDs, and status IDs. Three of those six come from the same admin CLI tooling used to manage the instance. Build the extraction layer once, and the agent knowledge falls out of it cheaply.

Three outputs come out the other side:

File	What it is	Who uses it
`active_rules_by_project.md`	Inventory table — name, trigger, author, rule ID	Humans doing a quick audit
`jira_automation_knowledge_base.md`	Every active rule in plain English, IDs resolved	The agent's knowledge source
`jira_automation_agent_instructions.md`	The agent's role, method, guardrails, escalation path	The agent's system prompt

They ship as a set. Never update one without the others.

The decision that made it work: script, don't re-reason

Here's the instinct you have to resist: just ask an LLM to read the automation JSON and write the knowledge base.

It's tempting. It's also slow, expensive, and — critically — non-deterministic (meaning: you get different output every time you run it). Every regeneration produces different wording. Diffs become meaningless. And you're asking a model to reliably translate ~190,000 characters of nested JSON without hallucinating a single conditional branch.

The script approach flips this on its head. The translation is deterministic: same inputs, same output, every time. That means:

Diffs are meaningful. Run a diff on the new inventory file against the old one and you see exactly what changed in the instance — rules added, removed, renamed, flipped on or off. No noise.
Regeneration takes seconds and costs nothing.
Hallucination risk on the knowledge base drops to near zero. Every sentence is emitted by a code path you can read.
The model's intelligence is reserved for the hard bits — validation failures, unrecognised component types, edge cases. That's the right division of labour.

The script is the specification. If you want to change how a trigger type is described, you change the code — not a prompt.

What "translation" actually involves

The script works in three layers.

Lookup tables first. Each reference export collapses to a dictionary: project ID → name, account ID → display name, customfield_* → field label, status ID → status name. There's also a hardcoded map for the ~18 system fields Jira doesn't include in the field export. Every raw ID in the rules gets resolved before a single sentence is written.

Recursive renderers second. The rule tree — triggers, conditions, branches, actions — gets walked and mapped to readable sentences. CONDITION_BLOCK becomes **IF** all of these are true: ... **THEN:**. A plain CONDITION becomes Only continues if ... — a hard gate that stops the rule dead. A BRANCH becomes **FOR EACH** ..., with nesting depth carried by indentation. Actions get their own renderer per type: edit field, create issue, create sub-task, transition, send email, link issue (using the link type's own inward/outward phrase, so it reads "this issue blocks it" rather than a raw ID).

Validation before anything ships. The script exits non-zero if it finds the word "unrecognised" anywhere in the output (a component type with no renderer), an empty value after a → arrow, or a leaked raw JSON array. A healthy run prints Validation: PASS. If it doesn't, nothing gets published.

That last one is the one that saves you at 11pm.

Claude Fable 5 did the heavy lifting in building the underlying parsing engine script. It was probably more model than the task strictly needed, but I had credits to burn and it was certainly fun to collaborate on.

Trust by construction

Here's the part worth stealing for your own projects.

Every resolved value in the knowledge base carries an inline confidence marker. Status names confirmed against the Jira export say (confirmed via the Jira status export). The one status ID that doesn't appear in the export — a since-retired status referenced by an old rule — says (inferred from this rule's own name). The "Known Limitations" section of the knowledge base auto-updates to name any affected IDs.

The agent instructions then bind the agent to that same distinction. It's instructed to preserve the confirmed/inferred language when it answers, and to say "I can't confirm that" rather than guess.

The chain is: the generator knows its own confidence → it writes that confidence into the knowledge → the agent is instructed to preserve it when it answers.

That's a reusable pattern. The quality of an agent is only as good as the data behind it — and most of the work went into making the source data trustworthy, not into prompting.

How it got here (the short version)

This agent didn't arrive fully formed — it went through three distinct versions before it was worth trusting.

The first version was LLM-authored and hand-curated: 9.7 KB, rules grouped by function category, a hand-compiled ID dictionary. Readable and useful — but it only covered a curated subset, couldn't be regenerated identically, and the ID dictionary silently drifted from the instance.

The second version switched to script-generated output and jumped to 192 KB — full coverage of all 61 active rules. But status names were still resolved from a hand-made reference document, so the knowledge base had to warn: "Treat inferred status names as a best guess." Rules rendered as transitions to status ID '10491' (name not resolvable).

The third version swapped the hand-made reference for a real Jira status export. That one change flipped the confidence language across the entire document:

Before	After
"per the technical reference document supplied"	"confirmed via the Jira status export"
"Treat inferred status names as a best guess"	"can be treated as reliable, with the following exception: `10331`"
`to status ID '10491' (name not resolvable)`	`to "Peer Review" (confirmed via the Jira status export)`

Unresolvable references went from several to one. And that one is honestly labelled.

Keeping it current

The knowledge base is a point-in-time snapshot. A rule created after the last generation is invisible to the agent until the next run. Disabled rules are excluded by design — the agent won't describe behaviour that isn't active.

The refresh process is straightforward:

Pull fresh exports from Jira and the admin CLI (topics for another article)
Run the script; require Validation: PASS
Spot-check one simple rule and one complex rule — two minutes
diff the new inventory file against the previous one; review what changed
Replace all three artefacts together

The agent instructions are a template, not a translation — the project list and escalation contact are the only dynamic insertions. Policy is a human judgement call, not something derivable from JSON.

Set a calendar reminder or automate the pipeline where possible. Future you will be grateful.

What transfers

The specific instance here is a Aussie Government Jira with 61 active rules applicable to a few Jira spaces, and one very patient platform admin. But the pattern works anywhere the gap between "what the tool does" and "what users understand" is wide.

The reusable steps:

Export the configuration in a machine-readable format
Write a deterministic script that translates it to plain English
Validate the output before it ships — fail loudly on anything unresolved
Label your confidence inline, at the point of generation
Constrain the agent to that artefact as its sole source of truth
Regenerate on a cadence that matches how often the config changes

The prompting is almost the easy part. The work is in the translation layer — and once that's solid, the agent mostly takes care of itself.

Wiring it up in Rovo

The agent configuration itself is deliberately minimal — which is part of the point.

In the Rovo agent builder, the knowledge section is set to Custom knowledge with a single source attached: a Confluence knowledge base named Ask Alfred (Jira automation interpreter). That's the 192 KB plain-English translation file — the one the script generates. No other organisational knowledge is enabled. The agent knows exactly one thing, and it knows it well.

Five Jira skills are also enabled — Get changelog, Get work item, Get editable fields, Get work item types, and Search with JQL — so the agent can look up live issue state when it needs to, rather than reasoning purely from the static knowledge base. The knowledge base explains the rules; the skills let it check the facts.

Three conversation starters are configured to give users a foothold:

What automations are set up for my project?
Why did this action trigger an automation?
How can I troubleshoot unexpected workflow behavior?

They're intentionally broad. The goal isn't to anticipate every question — it's to signal the shape of what the agent can do, so users don't open it and stare at a blank prompt.

I’ve since used Ask Alfred on several questions, related to automation behaviour, submitted by end users via JSM support. Each time, Ask Alfred has accurately pinpointed the likely issue and recommended a correct solution or a sensible extension to the existing automation — turning it from an interesting proof of concept into a genuinely useful first stop for support.

I always love hearing about the use cases dreamt up for Rovo Agents. If you've got some great ideas you've put into practise, please share!

Loom Upgraded Me to Business + AI Without Payment Information, Shows a $24 Balance, and Won’t Let Me

Dicle Naz Aslan — Sat, 22 Aug 2026 19:32:00 GMT

Hello,

I am experiencing a very frustrating issue with my Loom/Atlassian account, and I would appreciate help from anyone who has experienced something similar or from someone on the Atlassian/Loom team.

On July 29, 2026, I received an email from Loom informing me that I had started a free 14-day Business + AI trial, which would end on August 12, 2026.

The email clearly stated that in order to continue using the Business + AI plan after the trial, I needed to add payment information by August 12. It also explicitly stated that if I did not add payment information and remained below the user limit, my account would automatically be moved to the Free plan when the trial ended.

I never added any payment information. My billing page still shows “Payment info: None.” I also never knowingly purchased a paid Loom plan, completed a checkout for a paid subscription, or authorized a paid subscription.

Despite this, after the free trial ended, my account was not moved to the Free plan as stated in the email. Instead, it now shows Business + AI – Monthly, and I am receiving a warning about an unpaid balance. The billing page also shows an amount of USD 24.

I do not accept or agree to pay this $24 charge/balance, because I never requested a paid subscription, never added a payment method, and was explicitly told by Loom that without payment information my account would automatically revert to the Free plan.

This appears to directly contradict the terms communicated to me in Loom’s July 29 email.

To make matters worse, I now want to permanently delete my account, but I cannot do so. I have already deactivated the subscription, but it is still shown as “Deactivation pending.” Because this entitlement remains associated with my account, Atlassian will not allow me to delete the account.

I am asking Atlassian/Loom to manually remove the Business + AI entitlement immediately, remove the disputed USD 24 outstanding/unpaid balance, and allow me to permanently delete my account.

I can also provide screenshots of the July 29 email stating that I would automatically be moved to the Free plan, as well as my billing page showing “Payment info: None.”

I would appreciate it if someone from the Atlassian/Loom team could investigate and resolve this issue.

Using Smart Values in the Work Flow Post Function

David Frager _gmail_ — Sat, 22 Aug 2026 17:19:07 GMT

We have been using JIRA automation to update fields in an issues, and the updates rely on using Smart Values.

lately, we have started to hit limits in the number of Automation Requests, and because of that, our processes are getting disrupted.

We are not ready to jump to the higher levels of JIRA that provide increased automation.

I am looking for alternative solutions.

The Specific Use Case I am trying to address is:

* An issue owner enters a 1 line daily update.

* Automation will get triggered to take that 1 line update, pre-pend date / time / User Name and then add it to the top of a read-only field that has the full list of updates.

It would be great if this could be handled within the workflow post function, however, Smart Values are not supported.

I need to recover administrative access to I own [site].atlassian.net

Lleyam Bartholomew — Sat, 22 Aug 2026 17:05:06 GMT

I own lleyam.atlassian.net and need to recover administrative access to that existing site. I can authenticate successfully to my Atlassian account, but it reports that my account does not have access to Confluence on lleyam.atlassian.net. I have accidentally created additional organisations/sites while trying to recover access and do not want the existing lleyam.atlassian.net site deleted or replaced.

New issue creation screen lacks description editor toolbar

Zoltán Lehóczky — Sat, 22 Aug 2026 14:58:51 GMT

I wanted to submit a bug report for this under JRACLOUD but apparently, I can't create issues there.

The new issue creation screen lacks a toolbar for the description field's editor, which makes formatting (apart from what you may do with keyboard shortcuts) impossible:

Thus, you need to create the WI, then edit it, to be able to format it.

The Atlassian Friend #7: Invisible Architecture

Antonio Ferruz — Sat, 22 Aug 2026 14:37:44 GMT

Good architecture doesn’t remove complexity. It decides where complexity should live.

I’ve been thinking a lot about simplicity lately.

Not because software is becoming simpler.

Quite the opposite.

Every year we add more systems, more integrations, more security controls, more compliance requirements, more approvals, more automation, and now AI on top of everything else.

Enterprise software isn’t getting simpler.

It’s getting more complex than ever.

So why do some experiences still feel effortless?

That question has been stuck in my head for a while.

And the more I think about it, the more I believe we’ve been asking the wrong question.

We often say that good architecture reduces complexity.

I’m not sure that’s true anymore.

I think good architecture does something much more interesting.

It decides where complexity should live.

Imagine you’re an employee who needs help.

You don’t wake up in the morning thinking:

“I need to create a Jira Service Management request.”

You don’t think:

“I wonder which department owns this process.”

You certainly don’t think:

“Which request type should I choose?”

You have a much simpler thought.

“I need a new laptop.”

Or:

“I can’t log in.”

Or simply:

“Can someone help me?”

That’s your problem.

Everything else is ours.

As architects, engineers, and service designers, we sometimes forget that.

We spend so much time designing workflows that we accidentally ask employees to understand them too.

We ask them to navigate portals.

Choose categories.

Fill in forms.

Understand internal terminology.

Know which team owns what.

Provide information we already have somewhere else.

Little by little, we’re transferring our complexity to the people we’re trying to help.

Not because we intended to.

But because it’s easy to confuse process design with user experience.

The longer I’ve worked with enterprise platforms, the more I’ve realised something.

Complexity never disappears.

It always exists somewhere.

There will always be business rules.

There will always be approvals.

Identity management isn’t going away.

Neither are asset inventories, security policies, integrations, or audit requirements.

Pretending we can eliminate complexity is unrealistic.

But deciding who has to deal with it…

That’s architecture.

To me, that’s what invisible architecture really means.

The employee sees a simple experience.

Behind that experience, dozens of systems may be working together.

Identity is resolved.

Policies are evaluated.

Assets are checked.

Automations run.

Approvals are triggered.

Notifications are sent.

Records are updated.

Everything happens exactly as it should.

The employee doesn’t need to know.

And that’s not because those things aren’t important.

It’s because they are.

They deserve to be handled consistently, automatically, and reliably instead of becoming another burden for the employee.

This way of thinking has changed how I look at service management.

For years, we’ve focused on making portals better.

Better layouts.

Better categories.

Better forms.

But maybe that’s solving the wrong problem.

Maybe employees shouldn’t have to navigate our architecture at all.

Maybe architecture should navigate itself.

The employee simply describes what they need.

The platform figures out the rest.

This is why I’m so interested in the combination of conversational AI, service management, automation, and contextual data.

Not because AI replaces ITSM.

It doesn’t.

Not because conversations replace governance.

They shouldn’t.

But because conversations can replace navigation.

That’s a very different idea.

Instead of asking employees to learn how our organisation works, we can build systems that understand enough context to guide them naturally.

The complexity stays exactly where it belongs.

Inside the architecture.

Not inside the employee’s head.

Ironically, the more sophisticated an enterprise becomes, the less sophisticated the experience should feel.

That’s the paradox.

A single conversation may trigger twenty systems.

A simple request may involve security, HR, procurement, identity management, asset management, approvals, and automation.

The employee shouldn’t have to care.

Their job isn’t to understand our architecture.

Our job is to build architecture that understands enough to help them.

The more I think about it, the more I realise this article isn’t really about AI, Jira Service Management, or any particular technology.

It’s about a question I’ve found myself asking more and more over the years.

Who should carry the complexity?

For a long time, I thought architecture was about connecting systems, designing workflows, and making processes more efficient.

Those things are still important.

But today, I think they’re the consequence, not the goal.

The goal is much simpler.

When someone needs help, they shouldn’t have to understand how we’ve organised ourselves to get it.

They shouldn’t need to know how many systems are involved, who owns each process, or why a particular approval exists.

That’s our complexity.

Not theirs.

Maybe that’s what architecture has gradually come to mean for me.

Not removing complexity.

Not pretending it doesn’t exist.

But accepting it… and making a conscious decision about where it should live.

If we’ve done our job well, the employee never has to think about any of it.

They simply get on with their day.

And perhaps that’s one of the most satisfying parts of being an architect.

Building things that most people will never notice.

Not because they aren’t important…

But because they quietly did exactly what they were supposed to do.

Maybe that’s what invisible architecture really is.

About The Atlassian Friend

The Atlassian Friend is a series of stories, practical guides and personal reflections inspired by years of working with the Atlassian ecosystem.

Rather than simply explaining features, each article explores the ideas, patterns and experiences behind them.

To learn together, share openly, and grow as a community.

Have you ever participated in an Early Access Program?

I'd love to hear your experience.

See you in the next chapter of The Atlassian Friend. 💙

Can messages from Slack be added to already existing Trello cards?

Anne Steppe — Sat, 22 Aug 2026 14:08:17 GMT

Our small company started off years ago using Trello cards to track clients and their projects. We have recently started using Slack for all company communications. Can slack messages be added to already existing Trello cards?

I want a free subscription. i have se;ected it in the compare plans page but i dont see it chaning.

ThusathmiAtlassian — Sat, 22 Aug 2026 07:59:10 GMT

I dont want to have a premium. and i really dont want to pay for somehting i am not going to use. can you please check my account and then make it a free tier account?
thank you. my email is [email address removed for privacy]

Edit: Email addresses were removed from the post to avoid sharing personal information publicly and to align with the Atlassian Community Rules of Engagement.

How to get access to a space or space's source link?

Sagar Singh Rawat — Sat, 22 Aug 2026 05:05:14 GMT

I want to get access to the space's page "https://infosys.atlassian.net/wiki/spaces/TCOE/pages/1594459099/Getting+Started and the space https://infosys.atlassian.net/wiki/spaces/TCOE . How to get access to these pages and spaces? How to raise an IHD for this?

Regression Bug: Double-click to add a list is completely broken on desktop browsers

David W_ Jackman — Sat, 22 Aug 2026 02:09:09 GMT

Description:
The native layout feature where a user can double-click empty board background space to instantly trigger the "Add List" prompt has completely stopped working.

Steps to Reproduce:

Open any Trello board on a desktop browser.
Double-click an empty background area or space between existing lists.
Observe that no "Add List" prompt or input field appears.

Troubleshooting Already Attempted (Cross-Platform/Cross-Browser):
To isolate the bug, I have thoroughly tested and confirmed the issue persists across all of the following:

Operating Systems: Tested on both Windows (Lenovo Thinkpad) and macOS (Macbook).
Browsers: Confirmed broken on both Google Chrome and Microsoft Edge.
Isolation Steps: Cleared site cache and local data, tested fully in Incognito/Private windows, and completely disabled all browser extensions on Chrome on Macbook.

Because it fails across completely separate machines, OS environments, profiles, and browsers, this appears to be a recent platform-side regression bug. Please escalate to the development team to restore this critical power-user feature.

Confluence automation to archive inactive spaces

Don Hames — Fri, 21 Aug 2026 23:54:51 GMT

Hi everyone. I took on the "simple" task to write a Confluence Automation Flow that would archive inactive spaces. Since there is no configuration setting to turn off the auto-creation of a personal space whenever you join Confluence, it has resulted in thousands of personal sites that have never been used.

Sounds like a nobel idea to cleanup the unused spaces by deleting or archiving them, right? I know the conditions to check for:

trigger = scheduled

Branch Flow / Related Entities using CQL space.type = personal

AND {{page.count}} = 0

AND ( Last activity date is empty OR Last activity date is more than 180 days ago)

Then archive the space.

The issue I ran into is Confluence CQL does not appear to have a way to check the last activity date on a space. The space object seems to be somewhat limited.

This should be simple, until it's not. In Jira, this would take 20 seconds. Anyone had any success with attempting a Flow like this or something similar?

I truely appreaciate your input. Thanks.

Cannot link Jira and Bitbucket after linking Bitbucket to Organization

Edison Tam — Fri, 21 Aug 2026 22:40:45 GMT

My Jira and Bitbucket has been linked and working well for the past few years. This week, I noticed that my Jira tickets were no longer updating with their respective pull requests. Today I saw a popup on my Bitbucket that I am eligible to link the workspace to an Atlassian organization. I followed the instructions to complete this process.

Because I suspected the Organization change could have messed up the link, I went ahead and disconnected the existing Jira + Bitbucket link, but I am having trouble re-linking them now. In the "DVCS Accounts" section of Jira Admin, I click on the button to link Bitbucket Cloud and it properly finds my Bitbucket workspace (I blocked out the sensitive info in the screenshot):

However, after clicking "Grant access", I always see this error message. I have tried disconnecting and reconnecting multiple times. Is there anything else I should try? Is it possible that Jira is trying to link to an old Bitbucket workspace (the one before linking to an Atlassian Organization)?

Automation that will add a custom field value to a checklist

Christell Markham — Fri, 21 Aug 2026 22:44:19 GMT

Im trying to create an automation that attaches a card and the custom field value after the custom field value is updated.

Here's an example of the automation i made.

Everything looks right but when it gets to adding the item to the checklist it doesn't post the custom fields value.

Here's a screenshot showing the cards showing the custom field is updated.

EDIT: if i were to change the automation to make a comment on a card instead of the checklist it works like it should - the checklist would be the preferred method