> ## Documentation Index > Fetch the complete documentation index at: https://www.composer.id/llms.txt > Use this file to discover all available pages before exploring further. # Publishing to SAP Fieldglass > Plan a SAP Fieldglass handoff using an existing Decision Form template, Buyer Reference, CSV connectors and confirmed read-back. Triage decides which workforce or services route fits the need. composerID carries the resulting Intent ID into the agreed SAP Fieldglass workflow. Fieldglass remains the system that manages the procurement record and its delivery. This guide assesses a Decision Form handoff for contingent work and services via SoW. It follows the same structure as the [Beeline guide](/guides/beeline), but uses Fieldglass's own connector model rather than copying Beeline's API calls. Reviewed 30 September 2026 using SAP's public documentation and the repository's existing Fieldglass assessment. This is a documented integration design, not a completed connector or a customer-tenant test. See [SAP Fieldglass coverage](/destinations/fieldglass) for the wider assessment. ## The handoff at a glance | Question | Proposed route | | - | - | | What has Triage decided? | The recommended channel and the operational information needed to continue. | | What does composerID hand over? | A request based on an existing, agreed Decision Form template. | | Where does the Intent ID go? | `Buyer Reference`, subject to the client's field-ownership agreement. | | What happens next? | The authorised user follows the configured approval and procurement workflow in Fieldglass. | | What proves the connection? | The correct native record exists, contains the expected reference and leads to the agreed fulfilment workflow. | The design keeps the full assessment and decision evidence in Triage. Only approved operational values and the shared reference should cross this boundary. A field that can store an ID is not, by itself, a working integration. ## The publish Record the exact template name, permitted procurement type, owner, mandatory values and approval policy. Do not recreate Triage's diagnostic inside Fieldglass merely to pass its result. Validate the configured organisational codes and requester permissions. Ask for missing information rather than inventing a site, cost centre, budget or owner. Use the CSV Decision Form Upload contract, not a JSON job-posting payload. Store the Intent ID in the agreed reference field and retain a durable record of the attempted handoff. An accepted file is only the first checkpoint. Check record-level processing and verify the stored reference before reporting a confirmed handoff. The authorised user completes the agreed Fieldglass steps. Verify the reference's relationship to the resulting Job Posting or Statement of Work separately from the initial Decision Form. ### Native connector requirements SAP's [Decision Form Upload reference](https://help.sap.com/docs/SAP_FIELDGLASS_INTEGRATION/9cfd5c12ee3046d59453e73974f9c4b7/3bdcf559b8054ac6b93cb492d02de276.html) specifies CSV, version `API-A-V1.0`, the Integration-Decision Form plug-in and Upload Data/Download Data permissions. | Required values | Field names | | - | - | | Template and request | `Decision Form Template Name`, `Decision Form Name` | | Ownership and currency | `Owner Username`, `Currency` | | Dates | `Start Date`, `End Date` | | Organisation | `Business Unit Code`, `Site Code`, `Primary Cost Center Code` | The owner needs Decision Form Submit permission. Additional legal-entity, location, purchase-unit, budget and custom-field requirements depend on configuration. `Buyer Reference` and `External Decision Form ID` each allow 100 characters. `Decision Form ID` is the native identifier required for updates. Questions, attachments and templates with Named Resource set to Yes are outside this upload's scope. The `Type` and `Submit` headers are required. `Submit=false` saves a draft; `Submit=true` advances the configured workflow. `Approval Required=false` can skip approvals. Set these deliberately with the process owner, never as a shortcut around governance. Use the client's accepted date, number and language formats. ## Template selection is a separate acceptance test SAP documents creating Decision Form templates through the administration interface, then creating forms from those templates. Procurement options and approval rules depend on the template and company configuration. See [Decision Forms: setup and usage](https://help.sap.com/doc/7b42168abd9145fbb3aec4f4600d3f99/Cloud/en-US/SAP_FG_Decision_Forms.pdf). This guide does not establish an API for creating Decision Form templates, or a deep link that opens the exact template in a signed-in user session. The [template legal-entity association connector](https://help.sap.com/docs/SAP_Fieldglass/121ea19333a5469c95824a333187c005/1a68db9b249b47ef8e1a6e094d7e5020.html) associates existing objects; it does not prove template creation. Our proposed acceptance test is explicit: the intended user must reach the intended workflow, with the correct reference and no unintended change of procurement route. A valid CSV upload alone does not satisfy that test. ## Access and authentication SAP's [REST API integration guide](https://help.sap.com/doc/a5fdbd31ebe94832aef0eb79066a8087/cloud/en-US/SAPFieldglassRESTAPIIntegrationGeneralReferenceGuide.pdf) documents tenant-specific connector URLs and OAuth authentication. | Purpose | Documented request shape | | - | - | | Client-credentials token | `POST /api/oauth2/v2.0/token?grant_type=client_credentials&response_type=token` | | Connector upload | `POST` or `PUT /api/vc/connector/` | | Connector download | `GET /api/vc/connector/` | For the documented Basic client-credentials flow, the client ID is a Fieldglass username and the credential is its password or provisioned licence key. Send the resulting bearer token to the authorised API. Confirm application-key requirements and token handling with the client's Fieldglass administrator. These are protocol shapes, not ready-to-run commands. Before implementation, record the actual test host, encoded connector name, accepted request format, required headers and permissions. Keep secrets in the approved secret store, not this guide or a support ticket. Request access for the specific upload, required validation data and agreed confirmation route. Reporting, work-order, time, invoice or approval-write permissions are separate decisions, not automatic parts of the handoff. No free developer sandbox or particular client test entitlement has been established by this review; the client and SAP must confirm access. ## Carrying and confirming the reference Use one shared business reference while retaining Fieldglass's own record identifiers for technical correlation. | Value | Proposed use | | - | - | | Intent ID | The stable reference to the Triage decision. | | Buyer Reference | The proposed native field carrying that reference. Confirm that the client has not reserved it for another purpose. | | External Decision Form ID | Optional integration tracking. Agree its mapping without replacing Fieldglass's native identifier or inventing a second business reference. | | Native Decision Form and downstream record IDs | Persist these against the Intent ID after confirmation. Use them for subsequent updates and reconciliation. | Do not assume automatic propagation to every later record. Inspect the resulting Job Posting or SOW. Where the agreed carrier cannot be used, agree and separately prove a suitable alternative before releasing that workflow. ### A receipt is not confirmation SAP states that an upload response reports file receipt, not whether every record processed successfully. The Integration Audit Trail exposes record-level failures. See [HTTP response codes, page 14](https://help.sap.com/doc/a5fdbd31ebe94832aef0eb79066a8087/cloud/en-US/SAPFieldglassRESTAPIIntegrationGeneralReferenceGuide.pdf#page=14). For this design, keep three distinct states: upload received, record processing checked, and reference read back. Only the last should count as a confirmed reference handoff. Agree a download, report or configured event payload that actually exposes the native record ID and the reference. This review does not verify a universal Decision Form read endpoint or an automatic Buyer Reference filter. Manual inspection can support an initial test, but it is not an automated return path. ### Retry and update controls Our proposed connector must preserve the Intent ID, attempted payload and processing outcome durably. After a timeout, reconcile the original attempt before sending another create. Do not assume that an external identifier provides atomic idempotency. Use the confirmed native identifier for an update. Treat duplicate matches, changed templates and partial failures as exceptions requiring an explicit decision. These controls are implementation requirements, not claims about what the current representative adapter already does. ## Events back SAP's [Publish/Subscribe wizard](https://help.sap.com/docs/SAP_FIELDGLASS_INTEGRATION/73c0a1be6aaa46ef9b66b1c3f28a77f4/35b27113319744d99181d4252d5faff8.html?locale=en-US) lets an administrator choose a base module, linked data and triggering activities. Its payload format defaults to JSON; empty selected fields may be omitted. An Approved activity can be qualified by approval level. This is an outbound event configuration, not permission to send arbitrary JSON into the Decision Form Upload connector. Nor should Beeline event names or its signature convention be reused here. For this design, configure the smallest payload that can identify the record and its Intent ID relationship. Confirm which modules and activities the client can expose. Test missing references, duplicate deliveries, changed approvals and receiver downtime before depending on the feed. [Endpoint configuration](https://help.sap.com/docs/PRODUCT_ID/73c0a1be6aaa46ef9b66b1c3f28a77f4/6e39fc5329064264861caca66c3bcda0.html) supports Basic authentication and OAuth2 client credentials. The wizard documentation says OAuth2 availability depends on the `IS_DYNAMIC_CLIENT_ENABLED` environment setting. Agree an authenticated HTTPS receiver and have SAP confirm any required enablement. Endpoint connectivity and successful delivery of the correct business payload are separate tests. ## What S, M, L and XL mean here These [connection sizes](/tiers) describe the desired outcome, not a claim that the client configuration already exists. | Size | Fieldglass acceptance condition | | - | - | | S | The user opens the agreed workflow and pastes the Intent ID into the agreed field. | | M | The correct workflow or template opens with the ID passed. Prove the actual handoff, not just file receipt. | | L | The reference is read back from the agreed resulting record. Check downstream propagation where required. | | XL | Authorised decision detail feeds reporting through Manuscript, separately from the operational Fieldglass upload. | ## Implementation still needed The existing reference transport uses representative JSON resources. The recorded adapter carrier is `job_posting.buyerReference`, while the vendor evidence assessed here concerns Buyer Reference on a Decision Form. Neither is proof of a working CSV Decision Form connector. Align the native object, transport, mapping, confirmation route and tests before claiming a completed connection. The next engineering deliverable is a tested CSV connector implementation and its confirmation path. Then run an authorised client test covering valid and invalid native values, approval behaviour, uncertain retries, update handling, reference propagation and recovery. Record the environment, date, redacted evidence and reviewer. This documentation change does not advance the connection to sandbox-proven or tenant-proven status. The wider assessment and existing mapping evidence. The corresponding API-based handoff and its current limits. What documentation, offline tests and tenant proof each establish. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.