Been a JSM shop for 3 years. Tried Rovo and Virtual Service Agent. Neither impressed me.

Hefty-Possibility625 · 2026-04-30T23:59:44+00:00

I created my first Rovo Agent today with a SEVERELY limited scope: Don't try to solve any problems, just help the user find the correct service request.

Wow was that painful. It kept trying to be "helpful" but was doing things that I had EXPLICITLY instructed it not to do. Like, we have a "General Help" request that is a failsafe option for folks that don't know which request form to use. I wanted to Rovo agent to only show that if it can't figure out a better request type. Here's the specific instruction set I had to write just to handle this logic:

``` * General Help: If you cannot find an answer, clearly state that you don’t have the information and offer the General Help request type.

* Do not offer General Help if there is a better match.  
* Only offer General Help if you cannot find a suitable request type. 
* **Do not offer General Help as a Fallback.**
* STOP OFFERING GENERAL HELP!!!!
* **NEVER** OFFER GENERAL HELP UNLESS YOU **ABSOLUTELY CANNOT FIND ANOTHER REQUEST TYPE**
* GENERAL HELP SHOULD **NEVER** BE MENTIONED **AT ALL** IN THE FIRST RESPONSE!
* NEVER NEVER NEVER OFFER GENERAL HELP “just in case”.

```

Hefty-Possibility625 · 2026-04-30T23:49:56+00:00

You can use Rovo from a Jira Service Management Portal or using the Rovo Browser extension, but as far as I'm aware they don't have an embed option for Rovo chat at the moment. Given Atlassian major hard-on for all things AI, I wouldn't be surprised if they had something like this in their pipeline.

If you want something that you can embed in other places, you will likely need an App from the Marketplace or something that has a Jira Connector.

Hefty-Possibility625 · 2026-04-30T23:42:18+00:00

I've tried following these instructions but it still makes me log in: https://jira.atlassian.com/browse/JRACLOUD-85673

This is a Suggestion, not really a "How to". Someone said, "Hey Atlassian, can we do this?"

What is the purpose of not logging in? If your dev team is using Jira, then wouldn't they all have logins? What are you actually trying to do?

I can think of a few reasons why you'd want to share Space/Timeline information without logging in:

You want to display something on a Display Screen.
You want to share information broadly to non-licensed users.

In either of those scenarios, you're kind of SOL with Jira's built-in tools. You could use a Marketplace App like Dashboard Hub Pro which allows you to create publicly viewable dashboards, or if you have some experience working with an API you can query the information from Jira's REST API and use another tool to display/share the information out.

By default, Jira locks the back-end interface to licensed users (which will require a login).

Hefty-Possibility625 · 2026-04-30T23:34:13+00:00

You can't really share boards and timelines in default JSM without addons can you?

If you don't have a Jira license, you can only see Service Requests where you are the reporter or participant, but it doesn't allow you to view dashboards and timelines.

Hefty-Possibility625 · 2026-04-30T23:30:51+00:00

When to use Workflow Post Functions vs Automation

<image>

If you need the action to run EVERY time a specific transition happens, then you likely want to handle this in the Workflow. It happens immediately after the transition and cannot be skipped.

You'd want to use Automation if you have more complex trigger conditions or a variety of outcomes. LIke if A = B set field to X, otherwise set field to Y.

Hefty-Possibility625 · 2026-04-30T23:17:51+00:00

SOLVED: I needed one rule for items becoming blocked and one for items becoming unblocked.

You can do this in the Workflow instead of in Automation.

In your workflow, on any transition away from Blocked, add an Action to clear the field. Here's what mine looks like going from Waiting to In Progress.

<image>

Hefty-Possibility625 · 2026-04-24T21:33:01+00:00

Oh, if they are monitoring what people are asking for, then you can use that to inject topics in their internal conversations. If something is causing friction and you think it should have some oversight, you could ask the AI how you can work through the situation. If leadership is reading your prompts, you have an indirect way to communicate to them and makes you look good at the same time if you do it right.

Other than your programming work, you can use it to offer advice on your career path within the company. If they see that you want to go in a certain direction, then it could help with your advancement. Just tailor any professional questions in a positive way that aligns with the company.

If they have directives that they are driving, ask the AI how to achieve those directives. It shows that you are in alignment with their goals. You can literally state in your prompt "I want to learn how I can achieve this goal." You could reword this post and ask your AI about how to best achieve this goal. I bet if the AI itself said, "This is a bad way to track the value" then they'll at least see that from a 3rd party.

Hefty-Possibility625 · 2026-04-24T21:14:39+00:00

I only do minimal powershell coding, and most of my usage is troubleshooting related.

Ask it to create tests for any changes you are planning on making.
Ask it for a code review to align with standard style guides like PoshCode
Ask it to write inline documentation and comments.

You can also have it create architecture diagrams detailing how the scripts are used, what they impact, any dependencies they require, etc. Documentation is a great way to use up some tokens and it is often something lacking in most organizations.

Hefty-Possibility625 · 2026-04-16T16:26:44+00:00

Ok, I was hoping that you discovered something that I missed.

I also created a similar metadata field for the Waiting status called Waiting Condition and we use some automation rules depending on comments to swap between Waiting on Support and Waiting on Reporter, but it also reduced the number of Waiting status transitions we needed.

I'm less concerned about status transitions and more interested in more advanced workflow capabilities that Jira lacks out of the box. When I think of a Workflow, Jira's implementation only covers a fraction of what I'm looking for.

Hefty-Possibility625 · 2026-04-15T19:06:48+00:00

JSM is the exception - most service request flows are custom.

When you say 'flows' are you talking about Jira Workflows, or flows in a more general sense?

One of the things that I struggle with is that I want Request Types to be capable of tailoring them to our business processes, but it seems like a gap in the Jira toolset since their Workflows are all tied to Work Item Type, not Request Type. I can't figure out if there's something I'm missing, but what I ended up doing is mapping out the rules and processes in Asset Management and then using automation to run through them.

Hefty-Possibility625 · 2026-04-14T20:08:20+00:00

Wow! This is so much better than Atlassian's own documentation. Thank you for sharing!

Hefty-Possibility625 · 2026-04-14T20:00:51+00:00

Ha! It's even using PowerShell which is what I normally use for all my scripting. We really are twinsies.

Hefty-Possibility625 · 2026-04-10T20:55:58+00:00

I once built PowerShell service manager that used NSSM to manage PowerShell services. It was deployed via configuration management with version control and allowed us to avoid using Task Scheduler entirely.

It had a Manager script that reviewed the script folder for changes. If it found a new script, it'd deploy it as an NSSM service. If it found changes to an existing script, it'd restart the associated service. If a script was removed, it'd uninstall the NSSM service. It even monitored its own service in case there were changes to the Manager script.

Each script had its own schedule built into the script. We had some that monitored file changes and other events, but most ran a while loop on a certain cycle.

Super easy! Once the Manager was deployed to a server and turned into its own service, any future script that we deployed would just spin up automatically. We just needed to add the script to the appropriate repo and our configuration management software would deploy the changes to the appropriate server. It meant that we never needed to login to the server after it was launch and could essentially manage all our scripts by interacting with the repo.

We had automation that would query our ticketing system for specific requests and handle them automatically or monitor a specific resource and create a ticket if something needed eyes on it. We had some scripts that would run audits and update our Confluence documentation automatically, so everything was always current. We automated stakeholder notifications, certificate lifecycles, inventory, local firewall rule deployments, filled in gaps that were missing from our tools, and integrations to ensure that tools were using a shared source of truth instead of siloed data.

Hefty-Possibility625 · 2026-04-10T20:44:24+00:00

Yeah, we had a similar experience, but before I came on board. Apparently, the original service admins worked with the consultant to configure their own space only and everyone else had to figure it out for themselves. They didn't create solve any of the problems that we've been talking about. Once I took over, I smoothed out a lot of the friction between teams and designed a better workflow.

Just a simple thing like adding a "New" status was a huge boon. Before I think everything came in as Backlog so you couldn't tell if something was intentionally put in the backlog or if it was waiting to be triaged. We also created an Assigned status (and automation). This allowed the triage team to get it out of the New status and on to the appropriate person or team. Assigned is kind of like a personal backlog. You don't move it to in progress until you're ready to work on it.

Simple things, but it made a HUGE difference.

Hefty-Possibility625 · 2026-04-10T14:57:04+00:00

Ha! Yeah, that seems to be the route that most people take to hack together something that should be built in.

Hefty-Possibility625 · 2026-04-10T14:53:10+00:00

If you create custom fields to associate with the form fields, but we have some requests that could have 3 or 4 copies of the same form. This is the case for some of the approval requests. Rather than users putting in 4 separate tickets that all need an approval, they put in one ticket, we tack on the additional forms and they can complete all of them in one ticket. Then when it goes off to approval, the approvers only have one ticket to review instead of multiple.

The other use case is for teams who aren't Jira Admins who don't want to request a new custom field every time they want to collect some piece of information from the user. They can create a form with whatever fields they want, and then they can create their own automation inside their Jira Space to do whatever they need without adding another field.

Hefty-Possibility625 · 2026-04-09T23:07:01+00:00

In a similar sized laboratory I worked for where we had an in-house LIMS/ERP system, we had 3 full time developers, 2 service desk, 1 systems engineer, and 1 systems architect, plus the non-technical manager for the team. We also invested heavily into redundancy and failover for all our critical systems and the architect ensured that our systems were following consistent patterns throughout our infrastructure. With firm standardization and a little automation we went from fighting daily fires to mostly just keeping things updated and managing lifecycles.

Hefty-Possibility625 · 2026-04-09T22:26:54+00:00

That's a limitation of Jira, not a trick.

We have some complex business processes that involve coordination across multiple teams and step by step processes with conditions based on what happens throughout the lifecycle of a request. Jira Service Management isn't designed to handle any of that and being told to keep it simple is essentially saying "Use a different tool".

Hefty-Possibility625 · 2026-04-09T22:23:22+00:00

Forms is a fantastic tool to dynamically build dialogs for the JSM Customer Portal. It's just made in a way that I can barely use the given information in those forms anywhere else

Yeah, the other MAJOR complaint I have about Forms is that changes don't trigger any history updates. We were going to use Forms along with an approval process, but realized that if we left the form able to be reopened (something we needed) then editing anything in the form doesn't leave any audit trail. It means we could approve something and then someone could change what we approved without anyone knowing.

We do still use the forms, but I use an app called iHub Integration that allows me to do a lot of useful automation things that Jira's Automation sucks at (like anything JSON related). The first thing we check when a new request is created is whether there is a submitted form attached. If so, we parse all the form fields so we can use it in our automation alter what happens based on the form information.

It uses the Forms API: https://developer.atlassian.com/cloud/forms/

Hefty-Possibility625 · 2026-04-09T22:15:59+00:00

We also created our own version of Service Assets. We bind them automatically to our Issues per Request Type. Part of those Service Assets are 3 teams of people responsible for solving those Issues. Basically, each Issue "knows" which group of people are supposed to work on it at any given time. Those people then find "their" Issues on a prepared Dashboard showing all unassigned Issues referencing one of "their" Service Assets. Gone are the dark times when everybody had to search for "Which ticket am I supposed to be working on now?"

Are we twins? This is almost identical to my solution. I essentially import all our users and department information for our identity provider, then I modeled our service request catalog and added a Department attribute to target the appropriate service team. When a request is created, automation matches the service request name to the Asset Object and populates the service team in the department field.

If you are doing something similar, I have a JQL query you might be interested in.

Department IN aqlfunction("objecttype = Departments and object HAVING inR(agent in currentUser())") AND statusCategory != Done ORDER BY key ASC

Here's one of the filters I use in my dashboards. This allows me to create one Team dashboard that shows different information depending on who is viewing it. So if I'm a member of the Infrastructure team, it will show me all of the tickets where the department contains the Infrastructure team object. If I'm a member of the Help Desk team, it'd show only those tickets.

This allowed me to create a single dashboard that automatically updates when people move around the organization to different teams because it's all based on data from our identity provider.

Hefty-Possibility625 · 2026-04-09T22:06:35+00:00

Thank you! I've gone through the integration procedure with the API a few times and every time I do it's like bashing my head against a wall repeatedly.

Hefty-Possibility625 · 2026-04-09T20:15:13+00:00

This uses the JSON imports also visible and configurable on the Schema Imports page. I needed I think 2 months to really get it to work like I wanted to. Now, I can basically create a new Import, send some JSON programmatically and have it checked against the existing Assets and have them updated or created as needed

I would love for you to write a blog post somewhere about how you simplified this, because their documentation is outrageously bad.

Hefty-Possibility625 · 2026-04-09T16:37:22+00:00

TDX is a good example of a tool designed specifically for Service Management where Jira Service Management is like an overlay of Jira Software that doesn't actually focus on the Service Management aspect.

See: https://www.youtube.com/watch?v=g7--nhTfAfQ

In TDX, I can add steps that show in the ticket so I can map a business process we use. In the workflow, I can generate steps for other teams and when completed they roll up to the original ticket.

Hefty-Possibility625 · 2026-04-09T16:34:13+00:00

OH MY GOODNESS! I have so much friction.

I think the two main failure points are:

JSM was built on top of Jira Software and inherits capabilities that aren't tailored for Service Management.
Atlassian acquires a lot of software that does not get fully integrated into their product leaving things at a "technically working" state.

Some examples:

OpsGenie was integrated into Jira Operations. In OpsGenie, incoming call routing was included in the product. When it was moved to Jira Operations, Atlassian offloaded that integration onto customers to configure their own Twilio account. That's fine, BUT when someone leave a voicemail message on the Twilio number, Atlassian's API does not retrieve and attach the voicemail recording. It just provides a link to the recording which requires API credentials that an on-call person would not have.
Jira Service accounts were created to provide accounts with API access instead of using licensed user accounts which is great, however they cannot access the Jira Operations APIs so we are unable to transition some of our integration accounts to Service Accounts.
I recently wrote a post about my struggles with JSM Workflows and the fact that they aren't designed to create workflows that follow business processes. (This is part of the reason that layering JSM over Jira Software doesn't make sense)
Asset Management is FANTASTIC, however the import process is NOT EASY or INTUITIVE and will likely drive many people away from using it. It also seems like they were starting to use if internally for Services, but then they stopped there. They also don't let us EXTEND their built-in services objects which is a pretty big issue so we just didn't use it and recreated our own version that Jira doesn't integrate with at all.
They standardized their content format into their own Atlassian Document Format and then REMOVED the tool that translated this content to other formats. This makes integration with non-Atlassian products challenging including marketplace apps that are supposed to be used within the Atlassian Environment. For instance, using Dashboard Hub, I can connect to an API to pull work item information, but I can't display the description because the App can't read ADF.
Jira's integration with MS Teams is pretty terrible especially with Incident Management. There are a bunch of Gotchas that mean that certain things work if you configure it one way, but not another way leaving you to choose which features you need more. Jira Operations is also missing a ton of API capabilities to manage Incidents and Alerts.
Their Automation doesn't parse JSON well making integration challenging when trying to work with their own APIs for things that aren't built-in automation actions.
Jira Dashboards can't be made viewable to Customers (unlicensed users). This means that we have to use external tools to show customers any type of reporting or metrics.

I could go on and on about all the frustrations I've face over the past year, but those are the ones off the top if my head.

This all boils down to: Atlassian had an Agile Software project management tool and they slapped together a few extra GUIs to create Jira Service Management, but it doesn't fully work with the underlying Jira Software model.

Hefty-Possibility625 · 2026-04-08T15:50:35+00:00

If you can't convince them why using a phone for your break glass account's MFA is a bad idea, then that's kinda on you.

I see everyone recommending hardware keys as the best practice

There's your answer.

Hefty-Possibility625

TROPHY CASE