Skip to main content

Filter by idea status

10000+ Ideas

AndreyPoLevel 2

Introduce new permission to allow edits to projects pending approvalNew

Apologies in advance for submitting this as a new idea as there may already be an idea similar to this one: https://one.workfront.com/s/idea/0870z000000PSGvAAO. My goal is to expand on what's been proposed and suggest a UI element that could to introduced to control how this feature works.Currently, when a project is pending approval, it is locked so no updates can be made: tasks or items cannot be added, new comments cannot be made by users via the Updates area, custom data cannot be updated, etc. Although this generally makes sense from a compliance perspective (as a way to prevent users from "sneaking in" changes), there's a case to be made that certain folks should still be able to post certain updates and edit certain project data without having to restart the entire approval process. It's tempting to say that one should just "kick" the project record out from the approval process by adjusting the status, make the edits, and re-initiate approvals, however, it certain instances it's simply more trouble than it's worth, especially when an approval process has multiple stages with at least one [or more] of them involving senior leadership.Additionally, there may be automation processes that attempt to make certain functional updates to project records only to encounter roadblocks caused by these records being locked by a pending approval status. Thus, my suggestion for an enhancement would be to implement an extra permission for folks with Manage access to the project that would allow them to make edits during the approval process (see image). When non-system admin users with Manage access attempt to make an edit to a project that's pending approval, they should be given a warning message popup to help them understand that it's not recommended.Users with System Administrator access should always be able to edit a project when it's pending approval; this would allow system accounts / automations to perform project update actions on the background (regardless of the fact that there may be an active approval pending). Thank you!

Strip last two characters from UK postcodes when using geo zip to populate the Zip Code dimensionNew

Why is this feature important to you? I want to have a geo variable for UK users that can be classified and also used in data sources. This will allow us to combine our offline geographic segments with onsite behavioural data. It will also enable us to create calculated metrics such as "registration per local authority" so that we can analyse regional performance in Adobe Analytics. Using Geo Zip to populate the Zip Code dimension does satisfy these requirement except that it captures full UK postcode (e.g. HP22 5UY).  This is considered personal information because some postcodes contain only one address. We do not want to to collect and store this information as it may contravene the Data Protection Act 2018. However, if the last two characters were removed such that we only captured "4 digit" postcodes (aka Postal Sector, e.g. "HP22 5"), then these are sufficiently anonymous. How would you like the feature to work?An additional option in Report Suite Settings > General Account Settings.If the Zip Option is set to "use geo", then provide an additional configuration for UK postcodes ( 1. Use Full Postcode, 2. Remove Last Character, 3. Remove Last Two Characters, 4. Remove Last Three Characters).Current Behaviour?If a Geo Zip setting is enabled in Zip settings, then the Zip Code dimension is populated with a Full Postcode. Other NotesNB - I have considered the argument that because the postcode data is captured via IP address that it is too inaccurate to truly be personal data (insofar that you're not actually capturing someone's postcode but the nearest ping tower - or whatever Safari has produce). But I do not feel this would cover us in all situations. Separately, some of our use cases could be met if this other feature was implemented instead but on the other hand the idea was first raised 10 years ago (!)https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-ideas/out-of-the-box-reports-should-have-the-capability-of-being/idi-p/338900 

PhilHaNew Participant

SharePoint Search Results in "Docs"Delivered

Description - SharePoint integration - incomplete results when searching for applicable SharePoint site Why is this feature important to you - SAIF uses SharePoint throughout many of it's workflows, and this is a hinderance as we cannot find the SharePoint site we need quickly How would you like the feature to work - We'd like the results to not be phantom results, and we'd like to see more than 100 results when searched.  Current Behaviour - When we search for the SharePoint site that we need to access, while inside the SharePoint functionality within "docs" in a project - and search for the SharePoint site we need, multiple results are returned, and it appears some of those results are "phantom".    Note: this is captured in this open idea as well: https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/improve-sharepoint-graph-api-experience/idi-p/557242   Detailed Description The “Graph API” was recently updated from the previous legacy SharePoint integration. (An update in Workfront) Following the update, a piece of functionality in Workfront was impacted: the ability to search for files or folders in Workfront, but searching in SharePoint. It returns only 100 results (despite having potentially 1000s of results); when those results are returned, it points to “phantom” files that do not exist. For example, a search for “Adobe” rendered 3 results – the results are the exact match of the search term. In this example, 2 of the 3 results are empty – only one folder has data. The Workfront ticket, #344237 describes this issue we are seeing at SAIF. This same ticket also has an additional failure: when SAIF peoples are moving files and folders (inside of Workfront) to different SharePoint folder, or if the file has it’s named changed, then the Workfront metadata is lost for that file. This represents a substantive impact to our users’ workflows.