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 would you handle communication with a third-party vendor inside a JSM request?

Tim Braxton

JSM-Third-party comms suggestion.jpg

I had this idea where if you added a "Third-party" field to JSM and another communication channel to requests in the "Comments" section, where agents could open a channel in the context of a particular request to a third-party vendor or stakeholder. The reporter and request participants would be excluded from this collaboration. The "Third-party" field would have to be filled in order to send communication via that section of a request.

The purpose would be to handle and log business with third-parties through JSM email communication in the context of requests, further streamlining processes and maintaining more complete historical records. Invoices and files could be added as internal attachments to requests as they are emailed from vendors. You wouldn't have to add third-parties as request participants or agents, you would just put their email address or addresses in the "Third-party" field, then collaborate, and have it all logged for you.

Is there some way to do this now, better than the way I have described above?

Your suggestions are appreciated.

Accepted answers

Derek Fields _RightStar_

One approach would be to have a separate Service Desk that is specific to vendors. When you have a Service Desk ticket that needs Vendor input, you would have an automation button that would clone the ticket into the Vendor Service Desk and put the appropriate vendor as the Reporter. This would let them communicate on that secondary ticket, linked to the original, without them needing to be a customer.

All comments

Derek Fields _RightStar_

matthew barrett

That's an interesting idea.

Right now, I would handle this with a linked item. Create a new item with the vendor as the reporter (May need to add as JSM customer) and then all activity through email will be logged into that ticket per usual.

You could use a new type of work item so you can filter these out of all reporting to avoid duplicate metrics, or an automation rule when everything is completed to copy/paste the data into the main work item and cancel/archive the secondary work item.

A A Ron Geister _Trundl_

@Tim Braxton

I do love the idea you are proposing. I do believe it might be possible but in a different way. I also really like the ideas of both @matthew barrett @Derek Fields _RightStar_ as they are ways I have solutioned this in the past.

Dedicated vendor mailbox + automations
Use a dedicated mailbox (e.g., vendors@…) wired to JSM and drive outgoing/incoming with automations. You must ensure you’re using the JSM mail handler (per‑project) and not the global Core handler to avoid privacy pitfalls. Pros: simple infra; Cons: still no “compose to arbitrary address from the issue” UX without an app; careful config needed.
Store vendor email in Assets and automate mail
If you track vendors in Assets (object type “Vendor” with an Email attribute), you can select a vendor on the issue and use automation to send emails using that attribute. This keeps vendor details normalized and secure. Pros: single source of truth; Cons: still limited in email composition UX and threading controls

Lastly there are a few app vendors that do this so you can check the marketplace.

Email This Issue (META‑INF), and Enterprise Mail Handler (JEMH / JEMHC)

Tim Braxton

Thank you, @Derek Fields _RightStar_ I believe this to be the best method—as you could use the "Vendor Service Desk's" portal for external vendors to:

provide intake information (insurance, tax, and other forms);
submit invoices that do or do not have requests/work items tied to them;
ask questions.

Now, I'd most likely use this method over what I was initially proposing. Everyone here has outstanding ideas, I just feel this one suits my needs best. Thank you all for your suggestions.

The Atlassian Community is awesome!

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management