Skip to main content
redhatgr
Level 1
September 2, 2026
Question

Planning/Fusion/Core

  • September 2, 2026
  • 1 reply
  • 11 views

I’m currently trying to create a fusion scenario to map the Workfront Core project status to a Planning record’s status field so there is more parity between the two objects. I’m running into this very odd issue where for some Planning Workspaces I am able to successfully map the status but in other workspaces I can’t. I’m an Admin and the owner of all workspaces so I don’t think it’s an issue with permissions but given how complicated Planning sharing is I haven’t fully ruled that out.

The fusion scenario throws no obvious errors and appears to execute successfully, however in the output bundle I get is below, and I know the record ID it’s saying doesn’t match does exist:

 

 {        "body": {            "data": {                "status": "failed",                "total": 1,                "succeeded": 0,                "failed": 1,                "requestId": "[Request ID redacted for privacy]",                "results": [                    {                        "requestIndex": 0,                        "id": "[Record ID redacted for privacy]",                        "status": "error",                        "error": {                            "code": "FORBIDDEN",                            "message": "The provided key does not match any fields."                        }                    }                ]            }        },Anyone seen this before? There are not too many resources available on Planning to Core connections.

1 reply

etaylor-1
Community Manager
etaylor-1Community Manager
Community Manager
September 4, 2026

Hi ​@redhatgr , 

Thanks for sharing the details. Since the record ID is known to exist, the error may be related to the field identifier or value being sent rather than the record itself. Planning fields are specific to a record type, so different workspaces may use different field IDs or status options—even when the field labels are the same.

A few things to check:

  • Confirm that the record belongs to the expected workspace and record type.
  • In Fusion, reselect the workspace, record type, and status field instead of reusing mappings from a workspace where the scenario succeeds.
  • Compare the successful and failed bundles, including the workspace ID, record type ID, status field ID/key, and status value.
  • Retrieve the failing record first and confirm that the status field appears in the returned data object. Use the exact field identifier and status value returned for that record type.
  • If available in your environment, try the current Update a record (V2) module and map only the status field.
  • Permissions are still worth verifying, but the message The provided key does not match any fields is more consistent with a workspace/record-type field mismatch.

These references may help:

If the issue continues, comparing the input bundles from one working workspace and one failing workspace should help identify whether the difference is the field ID, record type, status option, or access configuration.

Terms & ConditionsAccessibility statement

Loading footer...