Calling JSM admins: what approval / sign-off edge cases should I be testing for?

[#1]

Hi all,

Quick bit of honesty up front: I'm a heavy Jira Software user, but I've had limited hands-on time in JSM day to day, so I'm hoping to tap the real-world JSM expertise in this group.

I'm working on validating an approval / business sign-off capability against real-world Jira Service Management setups, and the practitioners here know the edge cases far better than I do.

For those who handle approvals or formal sign-offs in JSM today, I'd really value your take on where things get tricky:

• Agent vs. customer roles: how do you handle approvals when the approver is a customer/portal user rather than a licensed agent?
• Portal permissions: any gotchas with what portal users can and can't see or act on?
• Request types and workflows: which request types most often need a formal sign-off step, and how do you model it today?
• Audit and compliance: what do your auditors actually ask for (SOC 2 / SOX / internal), and where does native JSM fall short?

Disclosure:

I'm an independent Marketplace vendor (Cahaba Forge). I built a Forge app, Business Sign-off & Approval for Jira, that adds audit-ready approvals directly in the issue panel. It runs great on Jira Software, and it technically runs on JSM too, but before I officially tag it JSM-compatible on the listing I want to make sure it holds up in real JSM environments, not just my test site.

If anyone is willing to try it on a real JSM instance and share candid feedback, I'm happy to provide an extended free license for your site. And even if you don't want to test anything, your answers to the questions above would genuinely help me build the right thing.

App listing for context: https://marketplace.atlassian.com/apps/1071447603/business-sign-off-approval-for-jira?hosting=cloud&tab=overview

Thanks in advance for any insight!

Jim

Cahaba Forge

[Natasja Eloff]

For JSM, I think the customer notifications helps with the Agent vs Customer role. Everyone that needs to approve the request will receive the notification.
This has the "View Request" button at the bottom of the email, that opens the Portal page with the request. and they can decided to either approve from the email notifications or click on the button to approve on the portal side.
I think the Agent can choose where they want to approve the request, either in the Portal or the Agent UI, it's up to them.

I do feel that the Customer Notification lacks the ability to add more detail.
Like custom fields, because this notification is for ALL approval requests. If you want to customize the notification, you need to switch this off and create a automation.
I have implemented a work-a-round where the details are copied to the description and this is then populated on the approval notification. But not everyone want's the field details again in the description.

I normally use the out of the box Service request with Approval. Or create a new Work Item.

Not really up to date with Audit requirements. but what I do know is they ask for the time-stamp of when this was approve. I have created a automation that captures this on a field named approval time-stamp. The data is captured on the request, but under Approvals and it's a bit difficult to get this in a filter.

[Rune Rasmussen]

From personal observations and experience, and in no particular order, these have been our common challenges:

Reminders. Or the lack thereof.
If you're a customer you only get a single email about a pending approval. And you only get one. Not everyone is glued to their inbox, and not everyone keeps it neat and clean, so the email notification can easily drown in the noise.

Picking the right approver for the right thing.
Sometimes it's a line manager, sometimes it's a service owner, sometimes it's Kevin from accounting.
If approvers are set by automation rules, keeping those rules up-to-date when a service changes owner, or Kevin retires, can only be done by an admin, but how does the admin know that Kevin is retiring?

Escalating.
How long do you want to wait before escalating the approval to the line managers manager? Or the service owner owner, or Kevins manager?
This could depend on whatever is being approved, but who decides? The Jira admin?

Unavailable approvers.
How do you know if someones line manager is on vacation or Kevin is on paternity leave?
You could let the reminder process run until it triggers an escalation, but if you already know that the approver is unavailable for an extended period of time it would be nice not having to wait.

Knowing who actually approved.
For approval steps with more potential approvers than is required, how do you know who actually did the approval?
You could use automation to clear your Approvers field and set it only as the user who triggered the event, but that may not be reliable enough for all implementations.

[Jim M _Cahaba Forge_]

@Rune Rasmussen - this is a fantastic breakdown, thank you for taking the time to detail these! You've highlighted some really deep operational challenges that native workflows struggle with.

A couple of quick thoughts on what you mentioned:

• Reminders: You hit the nail on the head here. The "single email that gets buried" problem is huge. I'm actually actively building out a configurable auto-reminder feature (setting reminders after X days) right now to address that exact gap!

• Knowing Who Actually Approved: This visibility gap is a major reason I built a dedicated audit trail into the app. Instead of relying on automations to clear or reset fields, keeping a permanent log (and CSV export) of who signed off, when, and on what exact version of the issue makes compliance audits infinitely cleaner.

• Escalations & Delegations: You raise great points on unavailable approvers and escalation paths. I'm taking notes on those for future roadmap considerations as the app evolves.

Really appreciate you sharing these real-world scenarios. It gives me a lot of clear direction on where to focus development next!

[Jim M _Cahaba Forge_]

@Natasja Eloff  - thank you so much for breaking down how you handle JSM approvals! That gives me a much clearer picture of how admins navigate this in real environments.

That automation workaround for timestamps makes total sense given the filtering limitations in JSM. Same with copying details into the description to get around those fixed notification layouts.

That distinction on Agent vs. Customer roles (portal-only customers who are still internal employees with company email addresses) helps a lot as I look at how panel apps interact with portal permissions versus internal Jira licenses.

Thanks again for taking the time to share your setup!

[Rune Rasmussen]

@Jim M _Cahaba Forge_ A thing we have found to be very helpful with the reminders is also informing the Reporter that we are awaiting approval, and who we are awaiting approval from.
Often that will motivate the Reporter to also reminder the approver to get to it, or they know if the approver is absent for whatever reason.

Along with the "Who approved?" gap there could also be a gap in "Who skipped approval?" for workflows with transitions that allows agents to skip an approval step.

The escalation & delegation thing is a bit more tricky I find.
Standard escalation can simply be Line managers until you reach the CEO.
For situations that require other approval flows I'm considering using Assets for that, once the new Services schema hits our site. Then anything that requires approval that falls outside the standard flow can have that entered into an "Escalation 1", "Escalation 2", etc... attribute.

Delegation on the other hand... It would require at least prior knowledge that someone is unable to approve.
I guess with the out-of-the-box features allowing bulk emails for comments could let you get auto-replies, such as Out of Office messages. But that also opens the doors for all sorts of other crap, and unless your company enforces a strict OoO message formatting catching and acting on it with automation is going to be unreliable at best.

[Jim M _Cahaba Forge_]

@Rune Rasmussen - Turning the requester into a second nudge path costs nothing, and it surfaces the absence problem earlier than any reminder schedule would. That's the one point here I have a partial answer for. The app ships a "My Approval Requests" dashboard gadget: a requester sees their open issues that have approvers attached, expandable to each approver's individual state. So "who are we waiting on" is answerable, but it's pull rather than push, so it complements a reminder rather than replacing one. Curious whether you think that's the right shape, or whether only the notification path really matters in practice.

A limit worth stating: the app does track each approver's individual state internally, that's how threshold rules like "75% approval" get evaluated, but it isn't projected into anything JQL can query. The synced approvers field carries the people without their states, so you can't express "still waiting on Kevin" as a query today. Your reminder point is exactly what makes that matter, and I'm looking at surfacing pending and approved account IDs on the issue property so JQL and Automation can both reach it.

"Who skipped approval?" is a good addition, and closer than I expected. The events are already recorded, the status change, who made it, and whether it came from the UI or a post-function, so it's in the audit export today. The issues themselves are findable with stock JQL:

    "BSO - Status" in ("Awaiting Decisions", "Approval Failed", "Not Started") AND statusCategory = Done

What's missing is a first-class view joining "this transition happened" to "these approvers were still outstanding." Same shape as the gap above: the data's there, it just isn't exposed...yet.

Modeling Escalation 1 / Escalation 2 as attributes on the service object is a clever angle. It gives you a data-driven chain without hardcoding it into automation rules, and it answers "who decides" by pushing that to whoever owns the service record. Curious how it holds up once the Services schema lands for you.

And I agree on delegation...Parsing OoO auto-replies works in a demo and falls apart in production. Without enforced formatting you're pattern-matching free text, and the failure mode is silently missing an absence, which is worse than not trying. My working answer is to not attempt detection at all: stop after a configurable number of attempts and tell the requester and/or assignee it's stopped, naming who went quiet. That doesn't solve delegation, it just makes the dead end visible instead of silent.

p.s. - Small gotcha from testing this: filtering on the BSO - Status field through the Advanced filter builder returned nothing for me, while the identical query in JQL mode returned the expected rows. Not sure yet whether that's specific to my setup, but if you hit an app field that looks empty, try JQL mode first.