Skip to main content

Day to Day Operations

Once the connector is set up, most of your ongoing work is processing approved requests and keeping configuration in sync.

Processing approved requests (write-back)​

When the portal finalises a request, the connector pulls it down and creates the matching BC record. This is the closing of the loop. There are two ways to trigger it:

  1. Manually from the Setup page. The Process Approvals action group has buttons for All Entity Types, Vendors, Customers, Items, Employees and any custom entity you have set up.
  2. On a schedule via Job Queue. Onboarding registers a Job Queue Entry that runs Process All Entity Types on a short interval by default.

The connector reports back to the portal once the BC record exists. The portal then marks the request as active in the ERP and stores the BC entity id alongside it, which is what makes the Raise Update flow work later.

If write-back fails, typically because of a BC-side validation error such as a mandatory dimension, the request moves to a failed state. Open the Request Log page to see the BC error message, fix the underlying BC data, then choose Retry on the Request Log row.

Vendor self-service​

A common workflow in Elevate Approvals is a vendor entering their own bank and tax details. The portal sends the vendor a tokenised link, the vendor fills in a public form, and the request resumes. From the connector's point of view this is just another approved request: when the workflow finishes you pick it up via Process Approvals exactly as for any other request.

Bypass detection​

The connector watches for changes to records that the portal manages (vendors created via Elevate, for example) when those changes happen outside Elevate. If someone edits the vendor directly in BC, the connector reports a bypass incident to the portal. Administrators see these in the portal's reporting screen along with severity and detection method.

This is informational, not blocking. It exists so finance and audit teams can detect unauthorised master data changes.

Operational tips​

  • Test in a sandbox first. Spin up a BC sandbox, install the connector against a non-production portal endpoint, and confirm the push and write-back loops both work before you point at production.
  • Field changes need a sync. Editing Field Configuration in BC does not automatically push to the portal. Always finish a session with Sync Field Configuration.
  • Do not push before the registry is ready. If you push entity data with Sync Enabled but the portal has no field definitions for that entity, the records arrive with no schema and admins will see only raw key-value pairs. Push field configuration first, then entity data.
  • Treat Last Synced At as authoritative. If a sync fails part way through, the watermark stays at its previous value and the next run picks up where it left off. Do not edit the watermark unless you are doing a deliberate full resync.