Migrating intake system from Jira Data Center to Jira Cloud

[Yasmim Piraja]

Hi, how are you?

Our team’s current intake system consists of a person sending an email to a gmail address and waiting on a reply.

I’ve set up an automation to create a Jira issue by using a webhook to an appscript I have in google workspace. It works by labeling these emails and uploading the labels once a Jira issue is created.

Although it works, in Jira Data Center we used to have an automation that allowed us to have the reporter as the person that sent the email (now it’s only automation for Jira, even though I’ve tried changing this field in the automation, I got some errors) and any updates/comments on the issue would be sent back to the reporter. Plus, any attachments in the email would pass through as attachments in the Jira issue.

Also, ideally the automation should allow those who aren't Jira savvy to reply to the email and have their input saved as a comment on the Jira issue and give acknowledgement when a issue is done.

Rovo told me this:

---------------------

Short answer:
Yes, you can get very close to your old Data Center behavior on Cloud, but not with Jira Software alone. To truly have:

• reporter = email sender (even if they don’t have a Jira license)
• replies to emails added as comments
• automatic “request received” + “request resolved” acknowledgements

…the native way is to introduce a Jira Service Management (JSM) project as the email front door, and (if you want) keep the current space as the internal delivery project.

Below I’ll explain why you’re hitting limits now, then outline two concrete architectures:

1. Recommended: JSM email channel + current space as internal project
2. Fallback (Jira Software only): keep your Apps Script + mail handler tricks, with some trade‑offs

---------------------

Is this accurate? Isn't there really a way to replicate the old Data Center behavior without creating a new space? Mind you, I'm not a Jira admin and I don't have the permission to create a new space.

[Olha Yevdokymova_SaaSJet · Accepted solution]

Hi @Yasmim Piraja 

Rovo’s answer is directionally correct — Cloud moved the “real email helpdesk” behavior into JSM. Jira Software alone won’t natively give you:

• reporter = external email sender (without them being a user)

• proper email threading (replies → comments automatically)

• automatic request received / resolved notifications

• attachment handling that just works

You can approximate it with Apps Script + webhooks (like you’re doing), but you’re essentially maintaining your own lightweight mail handler. It works — until it doesn’t.

Now, if creating a new JSM project (“space”) isn’t an option for you, there is another practical direction that some teams take:

You may try Smart Forms for Jira (built by my team), where you can:

• Create a public form (no Jira login required)

• Capture reporter email as a real field

• Map it to a Jira Email field

• Automatically send “request received” acknowledgements to this email

• Trigger “request resolved” emails based on status 

• Allow attachments

• Update status via follow-up forms

You essentially move from “email-driven intake” to “form-driven intake,” but keep the same automation-driven lifecycle.

For people who aren’t Jira-savvy, it actually ends up being simpler:

• They click a link

• Submit a structured form

• Get acknowledgement

• Receive updates automatically

No Jira UI exposure required.

If your org previously relied on ProForma in Data Center, that’s also worth mentioning: we’re currently preparing support paths specifically around ProForma → Smart Forms migration scenarios, since this exact Cloud transition problem comes up a lot. So if you also need some migration, we may discuss it.