IFS Cloud and Google Sheets integration

What moves between them

The primary flow is from IFS Cloud into Google Sheets. Purchase orders, supplier invoices, vendors, and GL accounts are queried from IFS on a configurable polling schedule (typically daily or weekly for master data, more frequent for transaction tables), and new or modified records are appended to their respective named sheet ranges. Deletions and corrections to IFS records are reflected as updates to existing rows in the sheet. The sync is read-mostly; ml-connector does not write financial transactions back to IFS, preserving the integrity of the ERP as the system of record.

How ml-connector handles it

ml-connector stores the IFS OAuth client credentials (client_id and client_secret) encrypted and exchanges them for a bearer token at the token endpoint, caching the token for its full lifetime and refreshing when a call returns 401. It constructs OData filter queries with modified-date conditions to retrieve only new and changed records since the last successful pull, respecting the 5000-element page size limit by making multiple requests if necessary. Each record is captured with its ETag value before being written to the sheet. When Google Sheets is the target, ml-connector maps IFS entity fields to sheet column headers you define, appends or updates rows using the Google Sheets API, and tracks the full lineage (timestamp, record ID, IFS state) so you can audit or replay the sync if a sheet formula returns an error. Rate limits from both IFS (HTTP 429) and Google Sheets are handled with exponential backoff and jitter. The service account credential for Google Sheets is stored encrypted and rotated when you upload a new service account key.

A real-world example

A mid-market procurement organization runs IFS Cloud for purchase orders and supplier invoice management across multiple cost centers and company codes. The finance team uses Google Sheets to report on outstanding POs, aging payables, vendor spend trends, and compliance exceptions. Before the integration, staff manually exported supplier invoices from IFS weekly, copied them into a master sheet, and checked for discrepancies with POs by eye. With IFS Cloud and Google Sheets connected, new invoices and POs flow into dedicated sheets on a daily schedule, sorted by vendor and due date. The compliance team uses a separate sheet to flag exceptions (missing POs, duplicate invoices, unusual amounts) and can click back to the original IFS record. Month-end reporting now starts with clean, current data instead of stale exports and manual reconciliation.

What you can do

• •Pull supplier invoices, purchase orders, vendors, GL accounts, and journal entries from IFS Cloud on a regular schedule.
• •Append new and modified records to named sheet ranges, keeping the audit trail complete and sortable.
• •Map IFS entity fields to sheet column headers you define, with no pre-built schema required.
• •Authenticate IFS with OAuth 2.0 client credentials and refresh the bearer token when calls return 401.
• •Track the full sync lineage (timestamp, record ID, source state) so you can audit or replay any record if a downstream formula fails.

Questions

Why is polling recommended instead of IFS Event Actions?

IFS Event Actions are powerful but require manual per-customer setup in the IFS admin UI - they are not self-registerable via API. Polling with timestamp filters is reliable and works across all IFS Cloud versions and deployments without manual admin intervention. ml-connector handles the complexity of rate limits and page size constraints so you get a simple, repeatable sync.

How does ml-connector handle the ETag requirement for IFS mutations?

ml-connector retrieves each IFS record and captures its ETag value before writing to Google Sheets. If you choose to write updates back to IFS in a future workflow, the ETag is available in the sheet for your own scripts to read and pass back to IFS on the PATCH call, enforcing optimistic concurrency.

What happens if Google Sheets is down during a scheduled sync?

ml-connector catches the error, logs the failure with full context, and retries with exponential backoff and jitter. If the outage persists, an alert is raised so your team can investigate. The IFS data is held in the queue and replayed once Google Sheets is back online, so no records are lost.