Jotform SharePoint Integration: What Works and What Doesn't

If you're reading this, you probably have a SharePoint list or document library and a Jotform that feeds it. That combination shows up constantly in enterprise: internal request forms, procurement workflows, HR onboarding checklists. The data needs to end up in SharePoint because that's where the rest of the org lives. For years the answer was 'build a bridge,' because Jotform didn't ship a native SharePoint connector and Microsoft didn't ship a native Jotform trigger. That changed on April 28, 2026, when Jotform released native Microsoft SharePoint and Excel integrations. If your SharePoint lives in Microsoft 365, you can now connect the two without a middle layer.

I worked on the integrations surface at Jotform, including the webhook pipeline and the third-party connector framework. The SharePoint gap came up in enterprise sales calls constantly, and it stayed open the entire time I was there. It closed after I left, in April 2026. So this note is two things: what the native integration actually does, and where I'd still reach for Power Automate or the Graph API instead.

The native SharePoint integration (start here)

If your SharePoint is on Microsoft 365 and your form data is reasonably flat, the native integration is the right starting point. It lives inside the Form Builder, it's maintained by Jotform, and it removes the connector-and-webhook plumbing that the rest of this note describes. You connect it once and submissions flow on their own.

It offers three actions:

1. Add Row to New List. Jotform creates a new SharePoint list and writes each submission as a row. You pick the site, choose which form fields become columns, and optionally include Submission ID (automatic) and Submission Date.
2. Add Row to Existing List. Jotform writes each submission as a row in a list you already have. You map form fields to the list's existing columns through a matching-fields step.
3. Send Files. Jotform uploads form files and submission PDFs to a SharePoint document library, with an option to create a subfolder per submission and to name those subfolders from field values.

Setup

1. In Form Builder, go to Settings, then Integrations, and search for Microsoft SharePoint.
2. Pick the action you want (new list, existing list, or send files).
3. Click Authenticate and sign in with your Microsoft account. SharePoint requires a work or school account, not a personal Microsoft account.
4. Select the target site, then configure columns or the matching-fields mapping.
5. Optionally send existing submissions retroactively so the list backfills.
6. Save. From then on, every new submission is sent automatically.

Where the native connector stops

The native integration covers the common case well. It is not a universal answer, and a few of its limits will decide whether you can stay on it or have to fall back to one of the paths below. These are the ones worth knowing before you commit:

• Work or school accounts only. It authenticates against SharePoint Online through a Microsoft 365 work or school account. Personal Microsoft accounts won't connect.
• No on-premises SharePoint. The integration targets SharePoint Online. If your SharePoint is a self-hosted Server 2016/2019 install, the native connector can't reach it.
• Multi-part fields don't split. A Jotform Name or Address field arrives in SharePoint as a single combined value, not as separate first-name and last-name columns. If your list needs the parts in separate columns, the native mapping won't do it.
• Widget data is one field. Widgets render in an iframe, so their data comes through as a single value rather than structured columns.
• Some hidden fields aren't selectable. A few hidden fields, such as Submission Date, don't always appear in the dynamic-field picker, while Form ID and Submission ID do.
• Throughput follows API limits. Sync is near-real-time but bounded by both services' API request limits, and large file uploads can lag on slow networks.

If none of those bite, you're done. You don't need Power Automate, you don't need a custom service, and the rest of this note is reference for the day your requirements outgrow the connector. If one of them does bite, keep reading.

When you still need a middle layer

There are three reasons to bridge Jotform and SharePoint yourself even though a native connector now exists: your SharePoint is on-premises, you need transformations or conditional routing the connector can't express, or you need multi-part fields split into separate columns. In those cases, here are the three paths, each with a different cost profile and failure mode.

1. Power Automate (Microsoft Flow) with a Jotform webhook trigger. The natural choice in Microsoft-first organizations and the only practical route to on-premises SharePoint. Requires either an Azure AD app registration for custom webhooks or the community-maintained Jotform connector.
2. Zapier as a middle layer. Jotform triggers a Zap, the Zap writes to SharePoint. Works well for simple flows. Gets expensive at volume because Zapier bills per task.
3. Custom webhook to Microsoft Graph API. You build an endpoint (Azure Function, AWS Lambda, or your own server) that receives the Jotform webhook and calls the Graph API to create the list item. Most control, most engineering effort, the only path that gives you arbitrary logic before the write.

Path 1: Power Automate

Power Automate is Microsoft's workflow automation tool, baked into most M365 plans. It has a Jotform trigger, but that trigger is a community-maintained connector, not a Microsoft first-party connector. Community connectors work, but they lag behind API changes and they don't come with SLAs. The reason to choose Power Automate over the native integration is reach: on-premises SharePoint via the data gateway, branching logic, and steps that run between the trigger and the SharePoint write.

Setup with the community connector

1. In Power Automate, create a new flow. Choose 'Automated cloud flow.'
2. Search for 'Jotform' in the trigger selector. You'll see a 'When a new submission is received' trigger.
3. Connect your Jotform account (OAuth or API key).
4. Select the form you want to trigger on.
5. Add a SharePoint action: 'Create item' for lists, 'Create file' for document libraries.
6. Map Jotform fields to SharePoint columns.
7. Test and activate.

Setup with a raw webhook (more reliable)

Skip the community connector and use Power Automate's 'When an HTTP request is received' trigger instead. This gives you a URL. Paste that URL into Jotform's webhook integration (Settings, Integrations, Webhooks). Now you control the payload parsing.

The tradeoff: you have to define the JSON schema for the incoming request so Power Automate can parse it. Jotform's webhook payload arrives in a 'rawRequest' field as a string. You'll need a Parse JSON step in your flow to extract the submission data before you can map it to SharePoint columns. It's more setup, but it's more resilient to API changes because you're reading the raw payload, not depending on a connector that interprets it for you.

The field mapping problem (Power Automate)

This applies to the Power Automate paths, not the native integration. When Jotform owns the mapping (the native connector), it handles most of these conversions for you. When you parse the webhook payload yourself in Power Automate, you own them, and this is where the debugging time goes. Jotform and SharePoint have different field type systems, and the mismatches aren't always obvious.

• Jotform date fields output in 'YYYY-MM-DD' format. SharePoint expects ISO 8601 with a time component. You need an expression in Power Automate to pad the time, or the item creation fails silently.
• Jotform dropdown selections come through as strings. SharePoint Choice columns expect the string to match one of the configured choices exactly. A trailing space or different capitalization breaks the mapping. You need a Compose step to normalize the value before the Create Item step.
• Jotform number fields output strings in the webhook payload. SharePoint Number columns expect numeric types. Parse and cast before writing.
• Jotform file uploads send a URL to the uploaded file. They don't send the file content in the webhook payload. If you want the file in a SharePoint document library, you need a separate flow step: HTTP GET the file URL, then create the file in SharePoint.
• Jotform multi-select (checkbox) fields output comma-separated strings. SharePoint MultiChoice columns expect arrays. Split the string in Power Automate before mapping.

File uploads in Power Automate: the separate step

The native Send Files action handles this for you: it uploads form files and PDFs straight to a document library. In the Power Automate paths you do it yourself, and this catches people off guard. Jotform's webhook sends a URL for each uploaded file, not the file itself. If your SharePoint target is a document library, you need a second action in your flow: an HTTP request to download the file from Jotform's CDN, then a 'Create file' action to write it to SharePoint.

Jotform's file URLs are temporary. They expire after a period (typically 24 hours for unauthenticated access). If your Power Automate flow has a delay or a retry that spans past the expiry window, the file download fails. The list item might already be created in SharePoint with a missing attachment. For production flows, handle the file download in the same flow run as the item creation, with no branching delays between them.

Authentication: Azure AD app registration

The native integration and the community connector both handle auth for you. If you use the raw webhook approach and need to write to SharePoint with application permissions (not delegated), you need an Azure AD app registration.

1. In the Azure Portal, go to App Registrations and create a new registration.
2. Add API permissions: Microsoft Graph, Application permissions, Sites.ReadWrite.All (or Sites.Selected for least-privilege).
3. Create a client secret and store it securely (Azure Key Vault, not in your flow definition).
4. In Power Automate, use the 'HTTP with Azure AD' action or a custom connector that authenticates with the app's client ID and secret.
5. Grant admin consent for the API permissions in Azure AD.

Path 2: Zapier as a middle layer

If you already use Zapier for other integrations, the Jotform-to-SharePoint path through Zapier is straightforward. Jotform is a first-class Zapier trigger. SharePoint is a first-class Zapier action. The field mapping UI in Zapier is friendlier than Power Automate's for non-technical users. With a native connector available now, the main reason to choose Zapier is that it's already your automation hub and you want one place to manage everything.

The problems: cost and latency. Zapier bills per task. A single Jotform submission that creates a SharePoint list item and uploads two files is three tasks (one per action). At scale, that adds up. The native integration and Power Automate don't bill per submission this way. Latency: Zapier polls Jotform for new submissions (typically 1-5 minute intervals on lower plans), while the native integration and Power Automate webhooks fire near-real-time. For internal workflows where people watch a SharePoint list for new items, the delay matters.

Path 3: Custom webhook to Graph API

For teams with engineering capacity and logic the native connector can't express, building a small service that receives Jotform webhooks and writes to SharePoint via the Microsoft Graph API gives you the most control. You handle retries, logging, field transformation, and error alerting yourself.

The Graph API endpoint for creating a list item is straightforward: POST to /sites/{siteId}/lists/{listId}/items with a body that specifies the field values. Authentication uses the same Azure AD app registration described above. The main reason to take this path: you need custom logic the native connector and Power Automate can't express cleanly. Multi-step transformations, splitting a Name field into separate columns, lookups against other systems before writing, or conditional routing to different lists based on submission content all fall here.

The downside: you're now maintaining a service. If it goes down, submissions stop landing in SharePoint and you might not know until someone asks where their data is. Add health checks, alerting, and a dead-letter queue for failed writes.

Enterprise-specific considerations

Regulated data and BAA coverage

If you're in a regulated industry (healthcare, finance) and your Jotform submissions contain PHI or other regulated data, the BAA question comes up. Jotform offers a BAA on Gold+ plans, and Jotform lists the native SharePoint integration as HIPAA-enabled. SharePoint Online is covered under Microsoft 365's BAA on eligible plans. The native integration is now the cleanest path for regulated data: there's no third party in the middle, so the data moves from Jotform to your Microsoft tenant directly. Confirm the HIPAA-enabled setting is on for your account before you route PHI through it. If you fall back to Power Automate, that also stays inside the Microsoft tenant; Zapier's standard plan is not HIPAA-compliant, and a custom service you host is under your own BAA with your hosting provider.

On-premises SharePoint

The native integration targets SharePoint Online and authenticates with a Microsoft 365 work or school account, so it does not reach on-premises SharePoint (Server 2016/2019). This is the clearest case where you still need a bridge. You can use an on-premises data gateway (Power Automate supports this) or authenticate directly against the on-premises SharePoint REST API (Windows auth, NTLM, or ADFS). The data gateway adds latency and another failure point. Custom webhook services can authenticate against on-premises SharePoint with proper network access, but that's more infrastructure work. Most teams running on-prem SharePoint that I've worked with end up using the data gateway.

What I recommend

• For most teams on Microsoft 365: the native Jotform SharePoint integration. Start here. It removes the webhook and connector plumbing entirely.
• If you need multi-part fields split, on-prem SharePoint, or conditional routing: Power Automate with a raw webhook trigger, or a custom Graph API service for the heaviest logic.
• For small teams already living in Zapier: the Zapier path is fine. Watch the task count.
• For regulated data: the native integration, with the HIPAA-enabled setting on, because it keeps the data inside the Jotform-to-Microsoft BAA boundary with no middle layer.

The integration itself is no longer the hard part for most teams: the native connector handles the common case. Where you'll still spend time is the edge cases, the field mapping when you fall back to Power Automate, and the authentication. Budget a day for setup and testing if you're on a custom path, not an hour. The SharePoint list that looks like it matches your Jotform perfectly on paper never does when you start pushing real data through it.