nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you maintain clear communication between dev teams and portal clients?

Jean Horn

Hey everyone! 👋

I recently came across a situation where a company’s support team only handled basic triage and initial customer contact. They didn't have specialized technical support.

To keep things moving, developers had to reach out directly to clients for technical details. Leaving that middleman role to general support would have created a massive bottleneck in the daily workflow.

My approach 🤠

I set up an automation where comments made by developers are automatically replicated in the linked support ticket.

While it solved the immediate issue, I’m curious: is this the best way to handle this scenario, or does it risk exposing internal communications?

Have you ever faced similar workflow bottlenecks between technical teams and clients? How did you solve them? 🤔

Comments

Amit Bansal_iakxzo

Hi Jean,

We follow a slightly different approach.

Once the initial triaging is completed by the L1 support team, the findings are added to the support ticket under the Internal Comments section in Jira Service Management, which is not visible to external stakeholders.

If the ticket requires code changes, we use those internal comments, along with the other relevant details from the support ticket, to create a separate ticket for the technical team (L2/L3 support) in a different tracker and assign it to the appropriate team.

Once the internal ticket is resolved, then L2/L3 team performs the necessary validation. Following successful validation, the support ticket is updated with the final resolution details and its status is updated accordingly.

Hope this approach gives you some ideas.

Best regards,

Sarah Wright_gz218r

Yes, and yes.
Is this the best way: generally yes, this is very a very common solution aside from increasing JSM licenses.

Does it risk exposing internal communications: also yes depending on the set up and people's ability to use the process.

You have a few options to reduce risk though really it boils down to ensuring that there is an explicit action that needs to be taken to add a public comment on the support ticket. It could be something like #public at the start of the comment to limit when the automation takes action.. It could be using a manually triggered automation to add a comment for public view. It could be adding the developer as a collaborator to the JSM project and restricting replication via automation to replicate the comment only when added directly to the item. It could also even be having a practice of setting comment security (it's possible but not advised to use this)

Ultimately it's what works best within existing work patterns and creating some safety protocols both via training and in the automations to reduce risk.

s_gridnevskii

Our L1 team works in Service Desk while L2 and developers stay in Jira. When support cannot resolve an issue it selects special status FOR DEVS in workflow. Automation rule creates an exact copy of the initial request in Jira and puts there all comments and attachments. Another automation rule in Jira closes support request when Jira issue is closed.

Unfortunately there is no direct communication between developers and customers, however if some details are needed developers contact support in Slack. Actually support does their job nicely and usually when case is escalated it already has all technical info.

We did not add developers to Service Desk since license costs a lot.

Sonal Nagpal Grazitti

This is an interesting scenario, especially because the challenge isn’t really the automation itself; it’s deciding what information should move between internal technical teams and customer-facing teams, and in which direction.

We’ve seen similar challenges in Salesforce & Jira workflows, where support teams need visibility into technical discussions without necessarily exposing every internal comment to the customer. A useful approach is to distinguish between internal collaboration and customer-facing communication, while still keeping the relevant context connected across both systems.

For example, teams can use selective/controlled comment synchronization rather than replicating every developer comment. This helps support teams stay informed while giving technical teams a space to troubleshoot openly without worrying about accidentally exposing internal discussions.

It’s also an interesting area to explore from an AI/automation perspective: how do we determine which technical updates are customer-relevant and should be surfaced to the support team?

This is actually one of the workflow challenges we’ve been exploring with Sinergify: how to keep Salesforce and Jira teams contextually connected while maintaining control over what gets shared.

s_gridnevskii

I want to add that developers may not know about special policy towards a specific customer. Imagine that company is in the process of signing a new agreement with a customer and developer says something that is technically true but may ruin all efforts to sign an agreement. Or for example say a rude word. Developers should do their job, support should do their. Dev team should not directly communicate with clients. Of course if it is a big company with established policies.

So I vote for indirect communications between developers and clients. Maybe through AI agent that checks developers answers against information that should not be passed externally.

Ata Oğuz

Hey Jean,

We have a marketplace app, Proxy Agent. Which lets non-service desk agents (users without SD license) to comment on service desk issues. Comment will be displayed under the name of the app, so customer will not see the name of the developer directly.

I work for the vendor of this app. Screenshot 2026-08-14 at 12.17.48.png Screenshot 2026-08-14 at 12.21.01.png

Jean Horn

Hi there!

Thanks a lot for sharing your workflow! That is a super solid approach for keeping internal technical discussions separate from external stakeholders.

In our case, we ran into a bit of a bottleneck when L2 escalated tickets to L3. Whenever L3 needed to ask the customer a clarifying question, having L3 ask L2, who then asked the customer, created a lot of unnecessary back-and-forth and slowed things down.

To fix this, we built an automation that allows the L3 team to add comments directly to the original request that are visible to the customer. It really helped streamline the communication flow and get faster answers!

Thanks again for dropping your perspective here!

Jean Horn

Thanks for dropping your perspective here!

Jean Horn

Hi there!

Thanks a lot for sharing your setup! It’s always great to see how other teams handle the escalation flow between JSM and Jira Software without blowing through license budgets.

We faced the exact same challenge on our side, and we also rely on automation rules to clone tickets and keep status synchronization completely seamless between both tools.

To solve the developer-to-customer communication gap without adding extra licenses, we came up with a pretty neat workaround:

Transition Screen: We created a specific screen attached to the "Pending Customer" status transition in Jira Software.
Dev to Customer Automation: We set up an automation rule triggered whenever a comment is added via that transition screen. If the status is "Pending Customer", the rule automatically copies that comment over to the linked JSM request as a public comment.
Customer to Dev Automation: Another automation listens for any comment made by the customer in JSM and replicates it directly back to the linked Jira Software issue.

This keeps our developers focused in Jira while giving them a direct, seamless line to the customer whenever they need clarification—all completely automated!

Thanks again for sharing your workflow and dropping your perspective here!

Hope this gives you some useful ideas! 🚀🚀

Jean Horn

Hi @Sonal Nagpal Grazitti !

Thanks a lot for sharing these insights! You nailed the core challenge—it’s definitely less about the technical automation itself and more about managing the boundaries of internal discussions versus customer communication.

Regarding the L3 and L2 collaboration piece, I completely agree. As I mentioned in my previous comment, we built a workaround to let L3 communicate directly with customers via a transition screen. However, finding a 100% seamless and risk-free solution for the L2/L3 internal dialogue alongside the customer flow is definitely an ongoing puzzle we're still refining.

Selective comment sync and smart visibility controls are huge here, and exploring how AI can help filter relevant technical context for support teams sounds like a game-changer!

Thanks again for jumping in and sharing your perspective!

Hope this helps!

Jean Horn

Hi @Ata Oğuz !

Thanks for sharing! That’s a really interesting approach to bridging the gap for non-JSM agents without blowing up licensing costs.

Quick question regarding the L2/L3 collaboration piece: does Proxy Agent also support internal comments/communication specifically between the L3 technical teams and L2 support, or is it strictly designed for customer-facing comments?

Thanks again for dropping by and sharing the app!

Hope this helps!

Ata Oğuz

Hey @Jean Horn ,

For internal comments/communication, you can use normal Jira comments instead. Our app is for customer comments.

Best Regards

Jean Horn

Thanks for getting back to me!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-service-management

jira-automation