Workfront detailed Audit type report

Forum|Forum|14 days ago
January 23, 2026
4 replies
41 views

I’m trying to identify Standard access users who are not involved as Assignee to any object except issue and Approval process and who haven't changed any object status.

Goal:
If a user with Standard access has never performed a Task or Project status change or not been an assignee (excluding comments, document uploads, or approvals), we’re considering moving them to a Light/Contributor license.

kautuk_sahni

Community Manager

@KatherineLa @Rafal_Bainie @RowvillBh1 @AmyReilly @KIMBERLYREA @KellieGardner Wanted to loop you in to see if you have any thoughts or best practices to share on this topic. Your insights would be highly appreciated!

Kautuk Sahni

KellieGardner

Community Advisor

There isn’t a way to get user details that DON’T meet the criteria; the best would be to get users who do meet the requirements and then compare-and-contrast.

You could use the journal entry report and narrow it down to the objects in scope for your purposes.

https://experienceleague.adobe.com/en/docs/workfront/using/reporting/reports/create-manage-reports/create-journal-entry-report

skyehansen

I can run through some of the general concepts but you really need to have some reporting chops to carry through to the end.

Much of the material you need in terms of how to develop these types of filters is in this recent webinar. In particular we show how even users who don’t have the text mode can beg, borrow or steal standard mode from other reports.

https://experienceleague.adobe.com/en/docs/events/workfront-recordings/workshop-rewind/workflow/master-exists-statements

What you’re asking for is a report with two filters. One filter is to show you who isn’t getting assigned to tasks (this is how I would define as “only involved as issue and approval process”). The other is who isn’t changing the status.

Both filters would go in your USER report.

Status: This presupposes that you are tracking the “status” field in your update feeds. This is a normal, default setting, so I only mention it in case someone switched it off in your settings area. If you’re tracking it, you would use an exists statement to pull in this information by pulling in the journal object. Your linking line would be the “editedByID” because this is the field for “who made the edit”. You can run a journal entry report and once you get it working, steal most of the textmode from that. An example of one that I made contains the following:

EXISTS:a:$$OBJCODE=JRNLE
EXISTS:a:editedByID=FIELD:ID
EXISTS:a:fieldName=status
EXISTS:a:entryDate=$$TODAYb-1w
EXISTS:a:entryDate_Mod=between
EXISTS:a:entryDate_Range=$$TODAYe-1w

EXISTS:a:$$EXISTSMOD=NOTEXISTS

Briefly: line 1 and 2 -- the object and linking line -- I am pulling in journal entry objects based on whether the user on your list made the entry. The next 4 lines represent the filter. Filter 1: “fieldName” is the name of the field that is tracking what field the change was made to. You’re looking for any change made to “status” field. I also threw in a filter for the date range. In this particular example, I’m only looking for status changes made last week, because otherwise it will be pretty slow-to-load and irrelevant, to be pulling up data from the beginning of time. (I would argue that nobody cares what status changes were made over a year ago -- especially if you’re talking about downgrading users. You should be more interested to know that no matter what, they haven’t done anything in the past year (in that case, switch out the “w” for a “y”.)

The majority of the lines in this exists filter will give you everyone who has done this. Now that you know that, just add the final, NOTEXISTS line, and you’ll get everyone who hasn’t done this. Which is what you’re looking for.

You’d use a similar filter for the task assignees. This time pull in the assignments object though. A sample filter might look like this:

EXISTS:b:$$OBJCODE=ASSGN
EXISTS:b:assignedToID=FIELD:ID
EXISTS:b:taskID_Mod=notblank
EXISTS:b:entryDate=$$TODAYb-1w
EXISTS:b:entryDate_Mod=between
EXISTS:b:entryDate_Range=$$TODAYe-1w

EXISTS:b:$$EXISTSMOD=NOTEXISTS

Again: lines 1+2 = your object and your linking line. You are pulling in assignments where the person assigned to the assignment is on your user list.

The majority of the other lines = your two filters. One says it has to be a task (taskID is not blank) and the other I just gratuitously threw in for the example: a date range that says it happened last week, but you can change it to last month, last year, past year, just by making an assignment report, building your filter, and then stealing the text mode.

Once more: if you can make this filter work, then you can make the opposite work too -- just add the final line: people in your list are not showing up as a task assignment in the past week/year/whatever.

skyehansen

edited to add -- I see that this is your first post, so in case you don’t figure it out, a worthwhile, time-based filter to add is something along the lines of:

entryDate=$$TODAY-1y
entryDate_Mod=gt

Mostly the key is to test thoroughly to make sure you’re getting the right results. e.g. run an assignment report and make sure the names that are coming up are not in there.