Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

What am I missing? Pulling parent project form info as a calculated task field?


Level 9

I'm not sure where I'm going wrong here - I've searched a few posts but no such luck.


I'm trying to pull in the field A_B_C from the project, as a calculated field on a task form.


I've tried what it seems to be them both the PERIOD and the COLON between the project and field name. 



{DE: Project.A_B_C}


From a task report, I pulled the text mode of


but this didnt work either.


I'm 99% sure it's something minor but argh!


p.s. E-A-G-L-E-S Eagles!


7 Replies


Level 9

Hmm this seems to reference a view or a grouping. 


Is there not a way to capture this in a calcuated field?


Level 5

I've had to move away from using calculated fields for things like this because they only update when the task is updated - not when the source is updated.  Meaning that the field on the task may show an old version of the project field if:

- project record is updated

- AND task record is not also updated


If you're interested, I can share an example of how I'm using Fusion to work around this limitation.


Level 5

We're making this type of update in the following scenarios:

  • Project to Task (ex: copy related project attribute to task)
  • Task to Project (ex: make the go-live date a project level attribute; sum the value of work delivered based on task attributes)
  • Company to Task (ex: write the Project Company Name to a task field)
  • Company to Project (ex: copy custom data from a company record to the project)
  • Project to Company (ex: sum custom field - value - of projects delivered)
  • Project A to Project B (ex: copy attributes of a related project A to custom data on the project B)
  • Task to Task (ex: maintain what grouping of work child, grandchild, great grand... relate to)

The purpose for most of these is to support reporting or integration with Salesforce/Jira.


The below example is a combination of project to project and then project to task.


Level 5

This is a branch of a larger scenario based off of a project new/change watch event.



We use filters to determine if the scenario should work the event and if so, which branch the scenario should work.


This example is the following branch:



In our scenario we're bringing attributes about the product being implemented on to the implementation project. The first router is branching to determine if there is a product tied to the project or if not.

  • If so, we write attributes on the project and on related tasks
  • If not (like it was removed), we null the fields on the project and tasks



We parse the JSON b/c the "Olive Product" is attached to the implementation project by a typeahead field.



When then read the product record (which is stored as a project in Workfront)



And write the attributes to the implementation project's custom fields


The ifempty expression is key so that when a product is changed the related fields on the implementation project are blanked if there is not a value for that piece of information on the new product.


For projects that are not dead or complete (b/c those cause errors), we continue to update tasks.



First it's a search to find the relevant tasks



Then filter to ensure there are results (to avoid errors)



Then update the tasks that were returned by the search



The final step in an error handler that creates an issue in Workfront when the scenario fails.

  • This gives our admin team a queue to work
  • AND let's the scenario finish - meaning it'll keep working





Hi - have you tried {project}.{DE:A_B_C}


For calculations and valueexpressions, you separate out the referenced object from the field with the period, but it also needs its own brackets.  (For valuefield, you can just use a colon like you had)