You can use the text mode interface to create more complex views, filters, groupings, and customized prompts in lists and reports. By using text mode, you can access fields and their attributes that are not available in the standard mode interface.
For information and considerations about text mode before you begin, see Text Mode overview.
For a complete list of all our reportable fields and their attributes, see the API Explorer.
The following are common guidelines when building any reporting or list element in text mode:
Always use camel case when referencing objects or attributes in the Workfront database.
Keep in mind the hierarchy of objects in Workfront. The following differences exist between views, filters and groupings:
Example: You can display the name or GUID of the Portfolio Owner in a task view:
valuefield=project:portfolio:ownerID
You cannot group, filter, or prompt for the Portfolio Owner in a task view:
project:portfolio:ownerID=5808f4bc00790b270a9629dd128e63fa
In these examples, Portfolio Owner ID is three objects away from the object of the list.
For information about the hierarchy of objects in Workfront, see:
Use wildcards whenever possible to make your reports and lists more dynamic and avoid duplicating them for different users and similar timelines.
When referencing Workfront fields or their attributes in text mode, Workfront requires you to type their names in camel case. In this case, the single-name fields are spelled in lowercase. Compound fields are spelled according to the following pattern:
camelCaseSyntax
All reporting elements follow this casing pattern.
The characteristics of camel case are:
Example: To reference the Actual Completion Date of a project, the name of the field that you would use when building text mode reporting elements is
actualCompletionDate
.
The following similarities exist between the syntax of the sets of reporting elements below, when creating them using text mode:
The lines of code and syntax are similar for views and groupings.
For information about the key lines of codes for views and groupings when building them in text mode, see:
The lines of code and syntax are similar for filters and custom prompts.
For more information, see:
You may notice that the lines of code when building views and groupings are similar.
For information about creating views and groupings, see the following articles:
The most important line of code for a view or a grouping is the line that identifies the object referenced in the view’s column or the grouping. Depending on whether this field is a direct reference to a Workfront database field or a calculation between several fields, the line of code may start with
valuefield
or
valueexpression
.
Although the lines of code in the examples below are similar between views and groupings, always remember that every line of code for a grouping starts with the grouping number.
To group by Project Name in a project list or report, use the following line for the first-tier grouping:
>
group.0.valuefield=name
>
If you edit multiple columns in a view in the same column (as it is the case of shared columns), remember that every line of code for each column starts with the column number.
Use the following format to identify the first column of a view:
>
column.0.valuefield=name
>Valuefield
syntax overview for views and groupings
Valuefield=
is a key line of code in views and groupings that identifies the object you are referencing directly.
The syntax for directly referencing fields is identical for groupings and views.
The following rules apply when referencing Workfront objects using a
valuefield
line:
Use camel case to reference fields directly.
Example: To reference the Task Actual Completion Date in a task view, use the following line:
valuefield=actualCompletionDate
Use camel case and colons to separate fields related to one another for the same object.
Example: To reference the Project Planned Completion Date in a task view, use the following line:
valuefield=project:plannedCompletionDate
For information about how objects are referencing one another in the Workfront database, see the API Explorer.
When referencing a custom field, use the name of the field exactly as it appears in the interface.
Example: To reference a project custom field labeled Additional Details in a task view, use the following line:
valuefield=project:Additional Details
Valueexpression
syntax overview for views and groupings
You can replace the
valuefield=
line of code with
valueexpression=
when building views and groupings in text mode when you want to reference a calculation between 2 or more fields.
Although you can build calculated fields which you can display in reports, calculated views and groupings are more dynamic. Calculated views and groupings refresh with new information every time you run the report or display a list.
For information about creating calculated columns in a view, see Calculated custom fields vs. calculated columns.
Building a calculated grouping is similar to building a calculated column in a view.
The following rules apply when referencing Workfront objects using a
valueexpression
line:
Use camel case to reference fields directly and enclose each field in curly brackets.
Example: To display the Task Name field in a task column using
valueexpression
, use the following line:
valueexpression={name}
Use camel case and periods to separate fields related to one another.
Example: To display the name of a project concatenated with the name of the task in a task report, use the following lines:
In a view:
valueexpression=CONCAT({project}.{name},' - ',{name})
In a grouping:
group.0.valueexpression=CONCAT({project}.{name},' - ',{name})
For information about how objects are referencing one another in the Workfront database, see the API Explorer.
When referencing a custom field, use following rules:
Example: To display the Additional Details project custom field in a task view in a valueexpression line, use the following line:
valueexpression={project}.{DE:Additional Details}
You can use a wildcard in a
valueexpression
but not in a
valuefield
line.
For information about wildcards, see Wildcard filter variables.
Valueformat
overview
The second most important line of code in a view or grouping is the
valueformat=
line. This tells Workfront in what format to return the value you specify in the
valuefield
or valueexpression lines. Although you can use various formats for the
valueformat
lines, we recommend that you always use the following value when using
valueexpression
:
valueformat=HTML
The syntax for creating filters is similar to that for creating custom prompts.
You can create a custom prompt by first building a filter for the statement you want to include in the prompt. Connect all the lines of code in a filter by “&” without any spaces between the lines and that becomes your custom prompt.
For information about building filters and custom prompts, see:
For information about creating filters in text mode, see Edit a filter using text mode.
You can use the following elements to build filters and custom prompts in text mode:
A line of code referencing the object of the filter statement. Use camel case for the filter object.
A line of code referencing the filter object and the modifier for the value of the filter object. Use camel case for the filter object in this line.
When referencing ranges, this requires 2 modifier lines.
A statement connector that connects multiple filter statements:
AND
This is the default connector between filter statements.
OR
Statement connectors are case sensitive and always uppercase. “AND” can be omitted in text mode.
Wildcards to make filters more dynamic and customize them for the current time or the user who is logged in. For information about wildcards, see Wildcard filter variables.