How to integrate Unify with Microsoft Excel
To integrate Unify with Microsoft Excel, route a Play webhook to a receiver that adds rows to a workbook table through Microsoft Graph. The documented rows/add API requires delegated Files.ReadWrite permission and does not support application permissions. Your receiver must manage that authorized user context and verify the workbook result.[1][3]
- Connection
- Via webhook + endpoint
- Spreadsheets
- Tool
- Microsoft Excel
- Receiver → Microsoft Graph
- Data flow
- Unify → Custom receiver → Microsoft Excel
- JSON payload
At a glance
- Plan a delegated user context that can edit the workbook
- Choose the workbook, table, and exact row mapping
- Verify saved changes, including any session behavior
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
Use Excel when the team already has an agreed workbook-based process. A table gives the automation a clearer target than arbitrary cell positions, but ownership still matters. Decide who maintains the workbook and authorization, and keep formulas or review fields outside the incoming field mapping.
A good fit when
Teams with a defined Excel table and a maintainable delegated Microsoft authorization path.
Reconsider the plan when
If the process requires unattended app-only authorization for this endpoint, choose a different supported integration path before implementing the feed.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Access | Plan a delegated user context that can edit the workbook |
| Table | Choose the workbook, table, and exact row mapping |
| Persistence | Verify saved changes, including any session behavior |
| Ownership | Assign responsibility for revoked access and failed writes |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Populate a workbook review table
A team uses Excel to review selected prospect records.
Write to an agreed table without altering its business formulas.
- Choose the table and incoming columns
- Send one controlled record
- Reopen the workbook and inspect the saved row
Prepare for an authorization interruption
The user who authorized the worker changes role or revokes access.
Give failed writes an owner and keep pending jobs traceable.
- Document who owns delegated authorization
- Test a controlled access failure
- Restore authorization and inspect the recovered write
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
The intended workbook table contains the mapped fictional prospect row, visible after reopening the workbook.
Inspect the rows/add result and the saved table. If a session is used, confirm that it persists changes rather than treating an in-session view as proof of a saved update.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Microsoft Excel.
Can I append Unify records to Excel?
Yes, through a receiver that maps them to Microsoft Graph table rows and uses the required delegated authorization.[3]
Can I use application permissions for rows/add?
No. The endpoint lists application permissions as unsupported. Plan a delegated user context for this implementation.[3]
Do I need an Excel table?
This path writes to a workbook table identified by its ID or name. An arbitrary worksheet range is a different API path.[3]
Is a workbook session required?
The session header is optional for rows/add. When using sessions, choose persistence deliberately and reuse the session ID for the related operations.[4]
Does adding a row update an existing contact?
No. It adds rows to the table. Matching a prospect and updating an existing row requires separate logic.[3]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Requires supported delegated authorization and access to the chosen workbook
- This is a table-row feed, not general desktop Excel automation
- An expired or revoked user authorization can interrupt the worker
- No live workbook or Microsoft account was changed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Microsoft Excel workflow.
POST JSON to a receiver, then add workbook table rows
Technical setup reference
References and requirements for the Microsoft Excel connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An HTTPS receiver with an owner, input validation, and a durable job store
- A controlled test record and a deliberate policy for repeat delivery
- An Excel workbook accessible through Microsoft Graph with a defined table
- A delegated Microsoft authorization flow with Files.ReadWrite
- A worker that maintains authorization and selects the intended workbook and table
Choose the workbook table
Identify the drive item and table to receive the records. Define the columns and map each incoming value to a position in the table row.[3]
Use supported authorization
Configure delegated Files.ReadWrite permission and an authorized user who can edit the workbook. The rows/add API lists application permissions as unsupported; do not substitute an app-only client-credentials token.[3]
Add mapped rows
Call the documented workbook tables/{id|name}/rows/add endpoint with a values array. Collect rows in the worker when practical instead of issuing a request for every individual cell.[3]
Persist session changes deliberately
A workbook session is optional. If you use one for related operations, create a persistent session and send its workbook-session-id with the subsequent calls.[4]
Request configuration
- Method
POST- URL pattern
https://YOUR_APP.vercel.app/api/unify-to-excel- Headers
Content-Type: application/jsonX-Unify-Webhook-Key: YOUR_WEBHOOK_SECRET- Authentication
- Use a custom X-Unify-Webhook-Key header in the Play and validate it inside your receiver. This header is an example contract you implement, not a built-in provider credential. Keep destination authorization and token renewal in the worker.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"event": "prospect_handoff",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
The keys are an example handoff format, not required Unify field names. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
The sample is the receiver input. Build the separate Graph body with values as a two-dimensional row array. The worker controls workbook and table identifiers; they are not supplied by arbitrary prospect fields.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
An app-only token is rejected
Use the delegated permission flow documented for rows/add. Application permissions are not supported by this endpoint.[3]
Changes disappear after the session
Review whether the session was created with persistChanges enabled and whether subsequent calls used its session ID.[4]
Rows are duplicated after a retry
Review the receiver’s replay policy before retrying uncertain writes. Adding rows does not establish a business identity or an upsert rule.[3]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
