Your Team Lives in Microsoft. Your Projects Live in Jira. Here's How to Connect Them.

[#1]

Most Atlassian articles assume everyone working with Jira is also working inside Jira. But that's rarely true at larger organizations.

Your legal team is in SharePoint. Finance runs approvals through Power Automate. Half the company communicates exclusively in Teams. They don't have Jira licenses, they don't want Jira licenses, and no one's going to convince them to change tools.

Here's how teams are bridging Microsoft 365 and Jira using Smart Forms for Jira — without requiring anyone outside your Jira instance to touch it.

The Setup That Makes This Work

Smart Forms for Jira generates public form links. Anyone can open them in a browser, fill them out, and submit — no Jira account required. Each submission can be configured to create a new Jira work item or update an existing one, with form fields mapped directly to issue fields you define.

That’s the foundation. Everything below builds on it.

Use Case 1: A Request Form Embedded in SharePoint

Your SharePoint intranet is already where employees go for policies, templates, and company resources. It's a natural home for intake forms — IT requests, procurement, HR, change requests — anything that needs to go somewhere structured.

The setup

1. Create your form in Smart Forms for Jira. Configure it to create a new Jira work item on submission, with fields mapped to whatever your team needs: request type, priority, description, affected system, department.
2. Go to Settings → Share form and generate a public URL with the access level you want (anyone with the link, or verified Jira users only).
3. In SharePoint, add either:
   • a Quick Links web part that opens the Smart Form in a new tab, or
   • an Embed web part (iframe) that renders the Smart Form directly inside the intranet page (Smart Forms Cloud, plus tenant settings that allow external embeds).

Embedding note: SharePoint embedding may depend on your Microsoft 365 tenant settings. If your organization restricts external domains in the SharePoint Embed web part, use a Quick Link or button instead. The experience is still simple: employees start from SharePoint and open the Smart Form without ever touching Jira.

What the employee sees: a clean form on the intranet they already use. No redirect to Jira, no login prompt (for public access), no confusion about where to submit something.

What Jira gets: a fully structured work item with all fields populated, tagged with the source via a hidden field (for example, source=sharepoint-intranet), ready for triage.

Good for: IT helpdesk intake, procurement requests, onboarding checklists, internal change requests — anywhere the submitter is internal but not necessarily a Jira user.

Use Case 2: Power Automate Approval in Microsoft 365 → Jira Work Item Creation

This is the first half of a bidirectional approval pattern. Approval happens entirely inside Microsoft 365 — Outlook, Teams, or the Power Automate Approvals center. Once approved, the downstream work needs to land in Jira with all the approval context intact.

The typical gap: by the time the approval resolves, someone manually creates a Jira ticket from the email notification. 

Smart Forms URL parameter pre‑filling closes this gap.

Best practice: push all existing context into the form

Smart Forms supports pre‑filling form fields by passing values as URL query parameters. You set a {variableName} placeholder in a field’s Default Response, then append &variableName=value to the form URL. When the link is opened, those fields are already populated.

URL pre‑fill works with text‑based fields that support a Default Response (single‑line text, multi‑line text, URL, numeric). It does not apply to dropdowns, checkboxes, radio buttons, or date pickers, so pre‑filled context should go into text fields or hidden text fields.

Best practice: Use URL pre‑fill for context that already exists in Microsoft 365, such as requester name, department, approval ID, approval status, business justification, SharePoint item ID, or Power Automate run ID. Use hidden fields for anything that should not be visible to the approver but must stay in the Jira audit trail.

Power Automate flow structure

1. Trigger
   An MS‑side event that needs approval before becoming Jira work, for example:
   • a SharePoint List entry
   • a Microsoft Forms submission
   • a flagged Outlook email
   • a Teams message in a specific channel.
2. Approval action
   Use Start and wait for an approval. The approver responds in Outlook, Teams, or the Approvals app.
3. Condition branch: Approved
   In the Approved branch:
   • Build the Smart Forms URL dynamically using a Compose action.
   • Start from the base external URL for your form, for example:
     https://smart-forms.saasjet.com/external?token=YOUR_TOKEN
   • Append query parameters using values from the trigger and the approval step:
   &requestor=@{triggerBody()?['requesterName']} &department=@{triggerBody()?['department']} &requestDetails=@{triggerBody()?['details']} &approvedBy=@{body('Start_and_wait_for_an_approval')?['responder']?['displayName']} &approvalDate=@{utcNow()} 
   • In Smart Forms, configure matching text and hidden fields with Default Response set to {requestor}, {department}, {requestDetails}, {approvedBy}, {approvalDate}, {approvalComments}, {runId}, {source}.
4. Delivery
   Send the constructed URL via:
   • Send an email (V2) — to the Jira project owner, or
   • Post message in a chat or channel (Teams) — to the team that will review and submit the form.
5. Submit → Jira issue creation
   The recipient opens the Smart Form. All the context from the original request and approval is already filled in. They review, add any missing details, and submit.
   Smart Forms creates the Jira work item with all that context captured, mapped to appropriate Jira fields (including hidden metadata).

What this solves:

• MS‑side approvals (purchase requests, vendor onboarding, marketing campaign sign‑off, access requests) that need to become Jira work with the approval trail visible on the ticket.
• No more manual re‑typing from approval emails into Jira.
• A reliable audit trail: who approved, when, under which request, and from which Microsoft workflow it came.

Use Case 3: Jira Work Item → MS‑Side Approval → Jira Status Transition

This is the reverse direction. Work originates in Jira, but the approver is outside Jira — finance, legal, or an executive who lives in Outlook and Teams. They need to approve something, and based on their decision, the Jira work item should transition forward (or backward).

The typical gap: the approver gets a Jira notification email they can’t act on without logging in. They reply to the email instead. The Jira owner manually transitions the issue. The approval decision exists only as an email thread.

Smart Forms + Jira Automation closes that loop.

The setup

1. Create an “Approval Decision” Smart Form
   • Fields: Decision (text or single‑line text), Comments, Approver name.
   • Map these elements to Jira custom fields such as approvalDecision and approvalNotes.
   • Configure the form to Update existing issue fields on submission.
2. Auto‑attach the form to the relevant issue type
   • Use Smart Forms Auto‑attach so each new work item of a given type automatically gets this form attached.
3. Auto‑share form URL when the issue needs approval
   Create a Jira Automation rule:
   • Trigger: Issue transitioned to Pending Approval.
   • Action: Send web request (POST) to a Microsoft Teams incoming webhook or Send email to the approver.
   • In the payload, use the Smart Forms smart value to inject the form URL and pre‑fill context:
   text

   {{#issue.properties."saasjet.forms.formsSharedUrls"}} {{#if(equals(formName, "Approval Decision"))}} {{url}}&issueKey={{issue.key}}&requestor={{issue.reporter.displayName}}&summary={{issue.summary}} {{/}} {{/}}
   In the Smart Form, Default Response fields {issueKey}, {requestor}, {summary} will pull this context in via URL pre‑fill.
4. Auto‑transition Jira based on the decision
   You can set up in Smart Forms to auto-transit work item after form submission or 
   Create A second Jira Automation rule:
   • Trigger: Field value changed → approvalDecision.
   • Condition:
     • If approvalDecision = Approved → transition to “In Progress”.
     • Else → transition to “Rejected” or back to the requestor.

What this solves:

• Approval loops where the decision‑maker lives entirely in Microsoft.
• Every approval is documented, timestamped, and attached to the work item.
• No one outside Jira needs a Jira account to give approval — the Smart Form is the structured handoff.

Use Case 4: Use Jira as a Trigger or Action Inside Power Automate

You can also build the integration primarily from the Power Automate side. Microsoft provides a Jira connector that exposes Jira as both a trigger source and an action target.

What the Jira connector offers

Common capabilities include:

• Triggers, such as:
  • When a new issue is created
  • JQL‑based triggers
  • (Depending on connector version) other event triggers like issue closed or updated.
• Actions, such as:
  • Create a new issue
  • Get issue
  • Edit / update issue
  • Add comment
  • Transition issue
  • Assign issue.

Attachments are usually handled via HTTP actions to Jira’s REST API rather than a dedicated “Add attachment” action in the connector.

How this combines with Smart Forms

Pattern A — Smart Forms submission notifies an MS workflow

• A Smart Form is submitted externally → Smart Forms creates a Jira work item in your chosen project.
• Power Automate’s Jira trigger (“When a new issue is created” or JQL‑based) fires.
• The flow then:
  • posts a structured Adaptive Card to a Teams channel,
  • logs a row in a SharePoint List for reporting,
  • emails the account manager with key details.

Pattern B — MS workflow creates a Jira issue, then sends a Smart Form for additional input

• A Power Automate flow runs (triggered by a SharePoint List update, an email, a schedule, etc.).
• The flow uses Create issue to create a Jira ticket with basic fields.
• Smart Forms Auto‑attach adds a detailed form to that issue (for example, “Vendor Information” or “Technical Brief”).
• Jira Automation or another flow sends the form link to the appropriate person for detailed input (via email or Teams).

Pattern C — Jira issue transition triggers MS‑side actions

• A Smart Form response updates a Jira issue field and triggers a status change via Jira Automation.
• Power Automate’s Jira trigger picks up this updated issue and runs MS‑side actions:
  • create a calendar event in Outlook,
  • update a SharePoint List status,
  • notify a Teams channel.

Setup notes:

• The Jira connector requires a Jira account with appropriate project permissions and OAuth‑based authentication.
• Jira Cloud and Jira Server/Data Center have different connector variants — choose the one matching your environment.
• Triggers run on a polling interval (typically around a minute and up, depending on your plan), so there may be a small delay — usually acceptable for cross‑system workflows.

Use Case 5: Auto‑Share the Smart Form Link to Microsoft Teams via Jira Automation

Sometimes the flow starts in Jira, but the next step — usually an approval or extra input — has to happen in Teams.

This pattern uses Jira Automation’s Send web request action pointed at an incoming webhook in Microsoft Teams.

Example: Approval request from Jira into Teams

1. A work item is created (for example, a software purchase request submitted via Smart Forms).
2. It needs manager sign‑off before the team proceeds.
3. Instead of the manager logging into Jira, they get a Teams message with a Smart Form link.

Setup:

1. In Microsoft Teams, create an incoming webhook in the approvals channel and copy the webhook URL.
2. In Smart Forms, create an “Approval Decision” form with fields: Approved (yes/no), Notes, Approver name. Map responses to Jira custom fields and set Update existing issue fields.
3. Auto‑attach this form to your Purchase Request issue type.
4. In Jira Automation:
   • Trigger: Issue created (with a condition: Creator = Smart Forms for Jira, or Issue type = Purchase Request).
   • Action: Send web request → POST to your Teams webhook URL.
   • Payload (simplified):
   json

   { "text": "New approval needed: {{issue.summary}}\n\nRequested by: {{issue.fields.requestor}}\nAmount: {{issue.fields.budgetAmount}}\n\nApprove or reject here: {{#issue.properties.\"saasjet.forms.formsSharedUrls\"}}{{#if(equals(formName, \"Approval Decision\"))}}{{url}}{{/}}{{/}}" }

The manager receives a Teams message, opens the form, selects approved/rejected, adds notes, and submits. Smart Forms updates the Jira fields, and Jira Automation can move the issue to the next status accordingly.

Variations:

• Send an NPS or CSAT Smart Form link to Teams after a ticket is resolved.
• Notify a Teams channel when a high‑priority Smart Form is submitted.
• Send an escalation detail form to an on‑call engineer via Teams DM when an issue transitions to Critical.

Use Case 6: Microsoft Forms at the Top of the Funnel, Smart Forms as the Jira Bridge

In many Microsoft‑heavy organizations, Microsoft Forms is already everywhere. It’s familiar, license‑free for submitters, and non‑technical teams use it for surveys, requests, and feedback — but Microsoft Forms doesn’t speak Jira.

The integration pattern here is not “replace Microsoft Forms with Smart Forms.” It’s a two‑stage funnel:

• Microsoft Forms collects broadly.
• Smart Forms converts the submissions that actually need to become Jira work.

Pattern A: Broad MS Forms intake → filtered Jira work via Smart Forms

Everyone submits through Microsoft Forms. Only the submissions that meet specific criteria continue into Jira.

• Microsoft Forms hosts the “Product Change Request” or “Service Issue Report” form.
• Power Automate:
  • Trigger: When a new response is submitted.
  • Step: parse the response and apply conditions (for example, requestType = Incident AND priority = High).
  • If matched:
    • Build a Smart Forms URL with requestor, summary, details, priority as URL parameters.
    • Pass a unique msFormsResponseId as both a URL parameter and the default value of a hidden field in Smart Forms.
• The pre‑filled Smart Form link:
  • goes to the responsible Jira owner in Teams or email, or
  • is opened by a technical owner who enriches it and submits.

Result:

• Frontline staff stay in Microsoft Forms.
• Only “real work” reaches Jira, already pre‑structured.
• Hidden fields source=ms-forms and msFormsResponseId preserve the link between the Jira issue and the original Microsoft Forms response.

Pattern B: Two‑stage onboarding — short MS Form, detailed Smart Form

HR or hiring managers don’t need Jira. They submit a short request; the actual onboarding execution happens in Jira.

• Microsoft Forms collects: employee name, role, department, start date.
• Power Automate:
  • Trigger: When a new response is submitted.
  • Builds a Smart Forms URL for an “Onboarding Request” form with these values pre‑filled via URL parameters.
• Smart Form:
  • Uses conditional logic to show different sections based on role (Sales, Developer, Operations, etc.).
  • On submission, uses Create new issue to create an Onboarding issue plus subtasks for HR, IT, Security, Facilities (with help of Jira Automation).

Result:

• HR uses a simple Microsoft Form.
• Execution teams get a complete, role‑aware Jira package.
• Smart Forms acts as the bridge between a “business‑friendly” intake and an “engineering‑friendly” Jira workflow.

Pattern C: Cross‑team handoffs — marketing/finance in MS Forms, execution in Jira

Marketing requests a campaign in Microsoft Forms; development and design execute in Jira.

• Microsoft Forms collects campaign goal, budget, deadline, audience (or for finance: vendor, amount, justification, approver).
• Power Automate:
  • Uses Jira connector’s Create issue to create a preliminary Jira issue with basic fields.
  • Smart Forms Auto‑attach adds a detailed “Tech Brief” or “Design Brief” form to that issue.
  • Jira Automation posts a Teams message to the execution team with a link to the attached Smart Form, pre‑filled with the campaign name, dates, and owner from Microsoft Forms.

Why this works:

• Marketing/finance never open Jira.
• Execution teams see a consistent Smart Form brief, regardless of whether the source was Microsoft Forms, SharePoint, or something else.

Alternative no‑form path:
You can create Jira issues directly from Microsoft Forms via the Jira connector’s Create issue action — no Smart Forms in the middle. This is faster but sacrifices conditional logic, hidden metadata, validation, and the chance for a technical owner to enrich the request before it becomes Jira work.

Use Case 7: SharePoint List as a Trigger for a Pre‑filled Form

SharePoint Lists are the lightweight databases of Microsoft 365: vendor rosters, project registers, asset inventories, contract trackers. When a record hits a certain status — a contract expires, a vendor needs review, an asset is flagged — work should move into Jira.

Power Automate + Smart Forms URL pre‑fill makes this seamless:

1. Trigger: When an item is created or modified in a SharePoint List, with a condition such as Status = "Needs Review".
2. Flow: Extracts fields like vendor name, contract ID, owner, review type.
3. Construct URL:
   text

   https://smart-forms.saasjet.com/external?token=YOUR_TOKEN &vendorName=@{triggerBody()?['VendorName']} &contractID=@{triggerBody()?['ContractID']} &reviewType=@{triggerBody()?['ReviewType']} &owner=@{triggerBody()?['Owner/Email']} &source=sharepoint-list
4. Delivery: Sends the pre‑filled link to the contract owner via Outlook or Teams.
5. The owner opens the form, verifies/adds details, submits → Smart Forms creates a structured Jira work item for the review task.

This same pattern works for:

• Asset lifecycle requests (flag an asset in SharePoint → pre‑filled IT request).
• Employee offboarding (HR updates a SharePoint record → pre‑filled offboarding checklist form creates subtasks).
• Vendor assessment scheduling (contract date triggers a pre‑filled vendor review form).

---

A Note on Hidden Fields for Source Tracking

Across all of these scenarios, one small addition pays off significantly: hidden fields with source metadata.

In Smart Forms, any form element can be made invisible to the submitter while still mapping to Jira fields. Set hidden text fields such as:

• source = sharepoint-intranet, power-automate-approval, ms-forms-intake, etc.
• originId = SharePoint List item ID, MS Forms response ID, Power Automate run ID.

Map them to Jira labels or custom fields.

Every work item created through these Microsoft integrations will be tagged automatically. Your Jira filters, dashboards, and reports can immediately distinguish SharePoint‑originated requests from Teams‑forwarded approvals from direct submissions — without anyone manually labeling them.

---

Putting It All Together

If your organization runs on Microsoft 365 and tracks work in Jira, these aren’t edge cases — they’re how work actually moves.

Smart Forms for Jira closes the gap without forcing Microsoft users into Jira and without requiring Jira admins to maintain parallel intake systems. The form becomes the handoff:

• Microsoft tools stay the “home base” for business stakeholders.
• Smart Forms provides structured, validated intake.
• Jira remains the system of record for work.

The patterns above — SharePoint embedding, bidirectional approvals, Jira as a trigger/action in Power Automate, Teams webhook delivery, Microsoft Forms funnels, SharePoint List triggers — each solve a different version of the same problem: getting complete, structured data flowing both ways between where people work and where you track the work.