Wildcard filter variables overview
- Topics:
- Reports and Dashboards
CREATED FOR:
- User
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.
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
You can choose from the following user-based variables:
- My Reports
- My Projects
- My Tasks
- My Issues
- My Hours
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
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
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.
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.
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.
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:
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.