Currently, there is no ability to track if a user opens a project,
issue, request, or task. It would be helpful if there were an activity
log that would track what a user does in Workfront such as opening a
project. This activity log will be used by system admins and exportable
Currently, project owners can delete custom forms that have been added
as part of the template. This results in loss of data that cannot be
recovered. While there is a warning message when a user tries to delete,
there needs to be an option for the system admin to disable custom form
Any user can send a document for approval outside or within ProofHQ. It
would be nice if there was an option restrict the ability for certain
users to send documents for approval and from creating proofs.
As a system admin, I created several filters for reports for the users
that I am supporting. By default, I am the only one seeing the filters.
I went to share with others and now they are seeing the filters on all
of their reports. How can I set filters to show 1) only for that one
report and 2) be viewable by all users of that report? I know this is
probably straightforward and that I am probably missing something.
We have uncovered that changes to 'text fields with formatting' will not
show in the update feeds. This is a major trade-off in functionality for
the ability to do rich formatting. It would ideal if this were tracked
as the other fields are tracked especially since there is the option to
display changes in update feeds.
The 'Requests I've Submitted' label is truncated in the left panel menu.
Not sure if this is per design, but this has been viewed on various size
monitors. Ideally, this field should show the full name. While this does
not affect the user experience, it would be better visually if the
entire name shows.
Currently, there are set proof dispositions: Approved, Approved with
Changes, Reject, etc. It would be nice if we can add additional
dispositions. Understandably, the current dispositions point to specific
behavior. But what if we were able to add additional dispositions that
utilize the existing ones? In one of our use cases, the legal team
required specific wording that could not be configured. Had we been able
to change the wording, we would have been able to onboard that process.
The reject ...
Request queues should be independent of projects. Queues play such a
huge part of the overall system that having it buried amongst the
projects presents a risk and a liability to usability. It is very easy
to delete a queue by accident which will greatly affect the instance. If
queues were an option similar to templates, it will give system admins