Product ideas | Community
Skip to main content

10000 Ideas

PollyCoNew Participant

Audit log passed on by Adobe Admin Console to Workfront should display as actioned by the correct administratorNew

The current state is that we have to create users first on Adobe Admin Console in order to control that the user will be created as Federated ID. Unfortunately, one of the many disappointing things about Adobe Admin Console is that it can randomly create the user as Federated ID or Adobe ID if the user creation originates from Workfront. As we were also forced into Adobe Admin Console and there is already an Adobe Admin Console Systems administrator, we can only get Product Administrator access levels on Adobe Admin Console which does not provide access to the logs. The problem occurs in that when other product administrator or the Adobe Admin Console Systems Administrator creates/deletes a user on Adobe Admin Console, these appear as if actioned by the main Workfront systems administrator in the workfront logs which becomes an audit issue. We can't refer to the Adobe Admin Console logs quickly as that would require requesting from the Adobe Admin Console systems administrator every time we need to figure out a user creation/deletion log. While Adobe is aware that this is an issue and they are looking to rename the log to say system administrator in the long run, there is no ETA on this fix. I am writing this Idea to get this bug(!)/feature fixed as I don't understand how this is acceptable as an audit issue. 

MalcomBenitesFL
MalcomBenitesFLNew Participant

Feature Request: Blueprints Sharing Across Workfront InstancesNew

DescriptionI would like to have the ability to create blueprints of objects within my Workfront instance that can be easily shared with other sister agencies. For example, instead of exporting project templates as Excel files and emailing them for manual recreation, I would like to share 2-4 project templates as blueprints that can be directly imported into another Workfront instance.Why is this feature important?This feature is crucial because it significantly reduces time and effort, increasing efficiency and productivity. It eliminates repetitive manual processes and ensures consistency across instances, fostering better collaboration between teams and agencies.How should the feature work?Workfront could introduce a dedicated "Share" section within Blueprints that allows users to:Select project templates, including associated custom forms, assignments, predecessors, and constraints, to compile into a blueprint.Export the blueprint as a file that can be shared externally.Import the blueprint into another Workfront instance, where the recipient can:Open the blueprint in their Blueprints section.Adjust assignments, custom form fields, and other configurations as needed.Save the blueprint as a project template within their instance.This streamlined workflow would empower teams to collaborate more effectively while preserving template integrity.Current BehaviorCurrently, I need to manually export project templates as Excel files, email them to the recipient, and have them:Copy and paste task names into their instance.Manually recreate assignments, predecessors, constraints, and custom forms from scratch.This process is time-consuming, error-prone, and inefficient.

MalcomBenitesFL
MalcomBenitesFLNew Participant

Feature Request: Convert Paragraph Custom Field to Text Field with FormattingNew

DescriptionEnable the ability to convert a Paragraph custom field into a Text with Formatting field. This functionality would provide users with the flexibility to copy and paste formatted text from other applications and format requirements directly within Workfront using bullets, numbering, bold text, etc.Why is this feature important?This feature enhances user efficiency and maintains consistency within the Workfront instance by:Allowing users to format project requirements or other data directly in the field, reducing reliance on external tools.Eliminating the need to create duplicate fields just to add formatting capabilities, saving time and minimizing administrative overhead.Retaining existing custom fields without requiring redundant work to migrate data to newly created fields.How should the feature work?Within the Custom Form Builder:Click on an existing Paragraph custom field.In the field properties/attributes, navigate to the Display Type dropdown.Change the field type from Paragraph Text Field to Text Field with Formatting.Upon conversion, Workfront should:Preserve all existing live data as plain text (i.e., no formatting will be applied retroactively).Allow new data to utilize the formatting options available in Text Field with Formatting.This streamlined approach avoids data loss while expanding formatting capabilities for future entries. (See attachment for a dropdown screenshot.)Current BehaviorCurrently, this functionality does not exist. Users must create a new Text Field with Formatting, manually migrate data, and delete the original Paragraph field—an inefficient and time-consuming process.

brentradNew Participant

Allow date-time data types to work with filter operatorsNew

DescriptionIn Customer Journey Analytics, dimensions can be configured to use a date-time schema data type. For example, a dimension showing when a product was added to wishlist could use this data type. Despite dates being akin to numbers, they cannot be used with greater than and less than operators in fitlers. The recommendation is to allow for this type of functionality. Why is this feature important to youAllowing the use of operators on dimensions that use a date-time data type would be useful for filter creation. For example, let's say that a user wanted to see a list of customer IDs that added a product to a wishlist between September 20, 2023, and October 20, 2023. A dimension exists that captures the date that a product was added to a wishlist (Dimension 1), and the dimension's values are in date-time format. If filter operators worked with date-time dimensions, the user could build a filter with logic similar to "greater than or equal to Dimension 1 = Sep 20, 2023, and less than or equal to Dimension 1 = Oct 20, 2023". Currently, the user would have to list out 31 different dimension values to cover each of the dates from Sep 20, 2023, and Oct 20, 2023. How would you like the feature to workTreat dimension values with a date-time data type as numbers, which will allow greater than, less than, etc. operators to be used. Current BehaviourDimensions with date-time data types do not currently work with operators.

Harveer_SinghGi1
Harveer_SinghGi1New Participant

AEP SDK timestamp auto collection syncing with a server-side clock for accurate and consistent data.New

Description - The auto collection logic for xdm.timestamp field in the AEP SDK is currently dependent on the user’s local system time. This reliance on system time creates inconsistencies in event tracking and reporting (event timestamps show up way in past or future at times which means they are offset as compared to actual event time). This improvement proposes syncing the xdm.timestamp field to a centralized server-side clock, such as UTC, ensuring uniformity and accuracy in time data.Why is this feature important to you - Accurate and consistent timestamps are crucial for reliable event tracking, analytics, and reporting. Without this feature, data may be skewed due to discrepancies in user device clocks, clock skew or drift, or manual adjustments to system time. This impacts the quality of insights derived from event data. By syncing the timestamp to a server-side clock, the platform ensures more reliable and consistent data, making it easier to correlate events, generate accurate reports, and analyze user behavior.How would you like the feature to work - The xdm.timestamp field should automatically be synced to a server-side clock (e.g., UTC) at the point when an event is logged, regardless of the user's local system time. The SDK should request the server time whenever an event is triggered, and the server will provide an accurate timestamp to be used instead of the device’s local time.In the event of network issues or server downtime, a fallback mechanism could use the local system time to avoid event loss, but with clear flagging of the fallback event for potential time data issues.The feature should be seamless and require no additional action from the user or client-side developers once integrated into the SDK.Current Behaviour - The xdm.timestamp field relies on the local system time of the user's device. This results in discrepancies for reasons like if a user changes the time on their device manually or if there are differences in system clock accuracy. This can lead to inconsistencies in event timing, causing difficulties in correlating data, performing time-based analysis, and generating accurate reports.