Wildcard filter variables overview

Using wildcards, you can reference a generic user or date instead of a specific user or date. In this way, the elements you build are dynamic; the results change depending on the context in which they are used.

For example, filtering for $$USER.homeGroupID in a project report retrieves only projects associated with the Home Group of the user who is logged in.

You can use filter variables—also known as wildcards—when building the following elements:

Filters in lists, reports, and the Resource Planner
For information about Workfront filters, see the article Filters overview.
Advanced searches
For information about advanced searches, see the section Use Advanced Search in the article Search Adobe Workfront.
Calculated columns in views
Conditional formatting in views
For information about conditional formatting, see the article Use conditional formatting in views.
Calculated custom fields

Wildcard filter variables are not supported when referencing nested collections in a calculated column.

For information about calculated custom fields and columns, see the article Calculated custom fields vs. calculated columns.

Date-based wildcard filter variables

Date-based wildcard options can be used in combination with any date filter attribute. For information about adding a date-based wildcard to a report, see the article Use date-based wildcards to generalize reports.

NOTE
If you create a date and time calculation that doesn’t include a time portion, or that uses the date wildcards $$TODAY or $$NOW, the system uses the date according to the Coordinated Universal Time (UTC) zone, not according your local timezone. This can cause an unexpected date result.

You can choose from the following date-based wildcards:

$$TODAY

We recommend that you build date-sensitive filters using this wildcard so you avoid building the filter again tomorrow, next week, or next month.

For example, if you want to display all tasks due before today, you can use the following rule in a task filter: Planned Start Date Less Than $$TODAY.

$$TODAY is always equal to midnight for the current day.

$$NOW

This is similar to the $$TODAY wildcard but includes the current date and time. $$NOW is equal to the current date and time.

For example, if you want to display all hour entries provided up to the current time, you can do this by using the following rule in an hour filter: Planned Start Date Less Than $$NOW.

Note: This wildcard is not supported in the Resource Planner.

To indicate various periods of time and various points in time (future or past), you can combine the wildcards above with the following:

Attributes
q
calendar quarter
h
hour
d
day
w
week
m
month
y
year
Qualifiers
b
beginning of the period (without a specified attribute, defaults to beginning of the week: Sunday)
e
ending of the period (without a specified attribute, defaults to end of the week: Saturday)
Operators
+
add value to wildcard value
-
subtract value from wildcard value

For example, the wildcard $$TODAYb+2w refers to “2 weeks from the beginning of this week.” The wildcard *$$NOW+2h refers to “2 hours from now.”

User-based wildcard filter variables

IMPORTANT
If a filter or report contains a user-based wildcard filter variable, the results always show information filtered by the user who is currently logged in. When you share such a filter or report with another user, the wildcard retrieves information for the user looking at the report. The two users see different results.
For information about adding a user-based wildcard to a report, see the article Use user-based wildcards to generalize reports.

You can choose from the following user-based variables:

  • My Reports
  • My Projects
  • My Tasks
  • My Issues
  • My Hours
$$USER.ID
$$USER.categoryID
The $$USER.categoryID variable refers to a specific custom form associated with the logged-in user.
$$USER.accessLevelID
The $$USER.accessLevelID variable refers to the ID of the access level associated with the logged-in user.
$$USER.accessLevelRank
The $$USER.accessLevelRank variable refers to the access level rank associated with the logged-in user.
$$USER.companyID
The $$USER.companyID variable refers to the company associated with the logged-in user.
$$USER.customerID
The $$USER.customerID variable refers to the ID of the customer account associated with your environment. For your environment, there is only one possible value for this variable and it is typically used only when building integrations through the API.
$$USER.firstName
The $$USER.firstName variable refers to the first name of the logged-in user.
$$USER.lastName
The $$USER.lastName variable refers to the last name of the logged-in user.
$$USER.name

The $$USER.name variable refers to the full name of the logged-in user.

Note:

This wildcard variable works only when modifying a filter in text mode. You cannot use this wildcard in filters that do not support text mode. For example, you cannot use this wildcard in the filters in the following areas:

  • Resource Planner

  • Workload Balancer

  • Analytics

$$USER.homeGroupID

The $$USER.homeGroupID variable refers to the ID of the Home Group of the logged-in user. As a Group Administrator, you can use this variable to filter only for items that belong to the users in your Home Group.

For example, to see all incomplete tasks on projects in the finance group, use the following filter rules in a task filter:
Project: Group ID Equals $$USER.homeGroupID
Percent Complete Less Than 100

To see all incomplete tasks assigned to individuals in a specific group which is the Home Group of the logged-in user, use the following filter rules in a task filter:

Assigned To: Group ID Equals $$USER.homeGroupID
Percent Complete Less Than 100

$$USER.otherGroupIDs

The $$USER.otherGroupIDs variable refers to all groups (including the Home Group) associated with the logged in user's profile.

The functionality of this variable is similar to that of the $$USER.homeGroupID variable, except the results display information about the users who belong to any of the groups associated with the logged in user.

$$USER.homeTeamID
The $$USER.homeTeamID variable refers to the ID of the Home Team of the logged in user. As a team manager, you can use this variable to filter only for items that belong to the users in your Home Team.
$$USER.teamIDs

The $$USER.teamIDs variable returns a list of all the teams associated with the logged in user.

The functionality of this variable is similar to that of the $$USER.homeTeamID variable, except the results display information about the user who belongs to any of the teams identified in the filter.

$$USER.roleID

The $$USER.roleID variable refers to Primary Role of the logged-in user. Using this variable, you can report on tasks or issues assigned to a specific job role.

For example, to see all tasks assigned to the Primary Role of the logged-in user, you can use the following filter rule in a task filter:

Task: Role ID Equals $$USER.roleID.

$$USER.roleIDs

The $$USER.roleIDs variable refers to all job roles associated with the logged-in user. Using this variable, you can report on tasks or issues assigned to any of the job roles associated with the logged-in user.

For example, to see all tasks assigned to any of the roles associated with the logged-in user, you can use the following filter rule in a task filter:

Task: Role ID Equals $$USERID.roleIDs

Tip: The Task: Role ID Equals $$USERID.roleIDs filter rule exists in the built-in filters Unassigned Tasks In My Role and Unassigned Issues In My Role.

Object-based wildcard filter variables

You can choose from the following object-based wildcards:

$$OBJCODE

The $$OBJCODE variable refers to the type of an object.

In a custom form, when the form's selected object types are incompatible with a field referenced in a calculated custom field, you can use this wildcard to avoid the workaround of creating duplicate forms for those object types.

In the calculated custom field, you do this by including the wildcard in an IF expression so that the calculation can output different values for each of your form's object types.

For more information and an example, see the section Calculated custom fields in multi-object custom forms in the article Add calculated data to a custom form.

recommendation-more-help
5f00cc6b-2202-40d6-bcd0-3ee0c2316b43