Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Workfront Planning V2 POST /v2/record-types/{rtId}/fields returns null-Field lookup error for reference + formula creates

Open
#28 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Quiet
Tech stack
javascript
Domain
api, backend

Research direction

Start by reproducing the documented reference and formula POST requests and compare them with the scalar-field creates that succeed. Trace the implementation behind POST /v2/record-types/{rtId}/fields and add or update coverage so both field types return HTTP 201 without the null-Field error or timeout.

Written by the indexing model from the issue text.

Description

Is there an existing issue for this?
  • I have searched the existing issues
What feature should be added?

Affected surface:

  • POST /v2/record-types/{rtId}/fields with type: "reference"
  • POST /v2/record-types/{rtId}/fields with type: "formula"

API version: Planning API V2 (May 2026 GA)

Symptoms:
For type: "reference", the documented body shape (exactly per developer.adobe.com/wf-planning/api/v2):

{
  "displayName": "Campaign Capacity",
  "type": "reference",
  "referenceOptions": { "multiple": true, "recordTypeId": "Rt6a..." }
}

returns HTTP 404 with:

{
  "title": "Field with id null is not found",
  "errorCode": "ENTITY_WITH_ATTRIBUTE_NOT_FOUND",
  "messageArguments": { "entity": "Field", "attribute": "id", "value": null }
}

The handler is performing an internal Field.findById(null) lookup that is never exposed to or controllable by the caller.

For type: "formula" with any documented expression, the endpoint hangs ~75 seconds then returns HTTP 500 INTERNAL_SERVER_ERROR.

Sample requestIds (from today's traffic):

  • Reference field requestIds: c6013b15-aae6-499c-8702-a2124877d028, f2e87015-4718-4da9-924d-10229294acb6, daa5ebd0-de8c-4397-bd2d-6417eb443c2b, 102d7507-fc32-4196-9eca-52c3c78fb4af, bab6ce93-18b9-4e4b-8107-3557986c34d0, ea25a376-2d3c-4381-b17f-5666c900b8f7
  • Formula field requestIds: 7e4f0768-e9c2-44fe-b961-e6f5889bc6d0, 105bb253-f10d-44ba-96c5-71b15046a249, ddc01350-35a7-45c7-a512-83eeda67f1b5, 8c7a5aed-e8ee-4d00-ac6b-0439bb960e4e

Reproducibility: 100%. Every reference + formula create against this instance fails identically. Scalar field creates on the same endpoint (text, single-select, date, number, etc.) succeed normally - only reference + formula are broken.

Impact: Blocks any cross-workspace migration or backup/restore workflow that needs to recreate schema. Currently working around by importing scalar fields + records and re-creating reference + formula fields by hand in the WP UI.

What is the expected behavior?

Expected: HTTP 201 with the created field, per V2 spec.

How will this feature improve the user experience?

API

What would a solution for this issue look like?

No response

Dominant language
JavaScript
Stars
0
Forks
2
PR merge metrics
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AdobeDocs/Workfront-Planning-API

All issues in AdobeDocs/Workfront-Planning-API

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.