Adobe Workfront Core Developer Professional common mistakes
Adobe Workfront Core Developer Professional · Understand the traps and how to avoid them.
Creates a custom status such as "In Review" but leaves its Status Equates With value pointed at Complete (or Current), then reports, groupings, and automations treat the object as finished or not started.
The status label feels like the meaningful setting, so candidates skip the equate field entirely; Workfront actually uses the equate, not the label, to decide how the object behaves in reporting and object logic.
What to do instead
Decide the intended behaviour first, then set Status Equates With (Not Started / Current / Complete) deliberately for every custom status, and validate with a test project before rolling the status out across groups.
Writes a calculated custom field that references another custom field by its display label or camel-case guess, e.g. {Cost Center} or {costCenter}, and the calculation saves but returns blank or throws an error.
Native fields are referenced in camel case ({plannedCompletionDate}) while custom fields require the DE: prefix; the form builder does not validate references when you save, so the error only appears on a record.
What to do instead
Reference custom fields as {DE:Exact Field Name} and native fields as {camelCaseName}, copy the name from the field list rather than retyping it, and test the calculation on a record with known values before attaching the form broadly.
Treats skip logic and display logic as interchangeable when hiding a section on a custom form, then discovers that values already entered into those fields are missing from the record.
Both options hide fields visually so they look equivalent in the preview; in reality skip logic removes the section from the record and its data is not saved, whereas display logic only hides it while keeping the data.
What to do instead
Choose display logic whenever the data must be preserved and skip logic only when the fields genuinely should not apply; test both branches on a record that already holds values in the affected fields.
Builds a report filter as a flat list of rows expecting any matching criterion to qualify a record, then cannot explain why only records matching every single row appear in the results.
The standard filter builder joins rows with AND by default, and OR requires an explicit grouped block; the interface makes single-row OR selection tempting and gives no warning that the logic is not what was intended.
What to do instead
Group the alternative criteria into an OR block and keep the mandatory AND rows outside that group, then verify by running the report against a known record that should match only one branch of the OR.
Shares a dashboard with stakeholders and assumes they will see the same totals the developer sees, then handles tickets claiming the numbers differ per person.
Reports run with the access rights of the viewer by default, so object-level sharing and permissions change which rows each person sees; the dashboard preview always looks correct to its author.
What to do instead
Decide deliberately whether each report runs with the viewer's access or a specified user's access, test with a limited-permission account, and confirm viewers can reach both the dashboard and every underlying report.
Creates a global approval process, adds a field about it to the project's custom form or assumes it fires automatically, and the project never actually enters an approval.
Approval processes attach to the object itself, either at creation or later from the Approvals area; a custom form only stores data and never triggers the approval path.
What to do instead
Attach the approval process on the object (as a project or request setting, or from the Approvals tab), and if approval should move the object to a custom status, select that custom status explicitly inside the approval process settings.
Configures a request queue with topics, but submitted requests land in the wrong project or queue, or requestors cannot find the queue in the Requests area at all.
Publishing the queue, designating a default queue topic, and adding routing rules are three separate steps; skipping any one leaves requests unrouted, stuck on a topic, or the queue hidden from users.
What to do instead
After building the queue, attach the queue topics, mark one topic as the default, add routing rules (including a default rule) on the topic, and publish the queue; then submit a test request from a non-admin account and confirm the resulting object.
Calls the API with a filter on a custom field using the display label or an unencoded value, and receives an empty result set or a 400 error it interprets as "no such records".
The API expects the field's own name (DE:Field Name for custom fields) rather than the label, and filter syntax must be URL-encoded; spaces, colons and special characters silently break an unencoded query string.
What to do instead
Look up exact field names through the metadata endpoint, build filters as $filter=DE:Field%20Name=value with encoded values, and read the raw response body rather than assuming zero results means the data is missing.
Assumes a single GET request returns every matching record and hard-codes an authentication flow copied from a browser session when building an integration.
The API paginates results and applies default limits, and browser session identifiers expire, so testing against small datasets in a short-lived session hides both problems until production.
What to do instead
Page through results with $limit and $firstBy (or the next-page link) until fewer records than the limit come back, and use an API key or OAuth2 credential for integrations instead of a session cookie; log status codes and handle 401/429 explicitly.
Raises a user's access level, for example to Plan, to fix a "cannot see this project" complaint when the object simply is not shared with that user or their group.
Access level and sharing are two independent gates: the level says which actions are permitted, sharing says which objects are reachable, and the admin interface surfaces the access level far more prominently.
What to do instead
Check the object's Sharing list and its inherited permissions from groups, sub-groups, teams and companies before editing the access level; verify the result with Log in as, remembering that sub-groups inherit sharing granted to the parent group.