Build better products with our product team
We are unable to see and unable to track changes to the Duration field in the task updates. Other similar fields, such as Planned Completion Date, can be tracked so this functionality should be easy to add. Please add this field to the Update Feeds so we can track changes.Our task owners and Project Managers make frequent changes to Duration in our implementation and these changes are invisible on the task record. Once this is feature is available, we can track these changes, along with others, in a Journal Entry report.Thank you.
Description - It would be very helpful to create experiences natively in Visual Experience Composer for Target admins, save it back to AEM when necessary in a similar fashion to how AEM Asset Link works within the native Creative Cloud user interface. Why is this feature important to you - It allows Target users to embrace more features and functionalities of AEM without needing to leave the Target Visual Experience Composer.How would you like the feature to work - Natively within Visual Experience Composer; users should be able to access available Assets, make renditions of Assets within Visual Experience Composer, including Experience Fragments, and save any changes made within the session back down to AEM. Current Behaviour -
Since Proof can recognize text one of my editors thought it would be great if you could turn on spellcheck in there. Usually, they download and look at spellcheck in Word but it would save that extra step and might be possible.
My company has billing period that lies outside of a Calendar month, therefore we are unable to use the standard date prompts (e.g this month) to get the information we need. I have created custom prompts to get around this but it would save a lot of time if I only had to create them once and have them held in a library, rather than manually recreating on every report relating to revenue.I'm sure this would be very valuable to other companies that have their own anomalies
Queue details, specifically Queue topics, to be able to be referenced in custom form display logic. This allows a single custom form to be used for each request queue project. For each project, depending on the requestor's queue topic selection, display logic would populate form details applicable to only the selected queue topic.
We can now set the "Work on It" button to be a "start" button, but it only seems to apply to tasks involving a team. It would be even better if we could set this as a global standard. Otherwise it can be confusing that tasks behave one way if only users are assigned, but behaves differently if there is a team in the assignment.
Users are confused by the 'Not Done Yet' phrasing on the button next to assignments in Workfront. They are confusing that button with status. It would be more clear if this button read with something like "I'm not finished".
The current default "new form" experience is pre-populated with fields which have an "unset" or "empty" value for the Label Width and Field Width inputs (below, top). When the form renders in the Preview Draft mode, the label and field are both modified with an inline width style (100px and 150px respectively) although the input is empty by default (below, bottom). I'd at least expect the default values for the Label Width (100px) and Field Width (150px) to be preset to the values that populate by default so that there's some clue as to the relationship between the input and the output. Given that the input is empty, it'd be great to extend/refactor the script to consider an "empty" value as a way of not setting an inline width [attribute] on an element (which generally these days is preferred for responsive design). Better yet would be to remove the "px" appended to the value in the input (Label/Field Width) so that "400" outputs "400px" and rather take the exact value of the input to extend the functionality to other units (400%, 400em, 400px). This issue is not limited to just the Label Width and Input Width properties, you'll also notice on the top line of the bottom image (above) an inline style ending in "...; width: 271px;". This is the bottom line of the form element with a width of 271px. This value is not set in the form editor and rather it's implied - presumably as a total of other implied values like the width of the labels and inputs. Adding an input to actually set the width of the form on the user-end would be better than implying the width and creating a need for an "override solution" in the default context. Most often, this issue is solved with CSS by overriding the ".mktoHasWidth" class with a setting of "width:auto !important;" to override the inline styles -or- with JS by removing the style="" attribute from all the form elements (the nuclear option). At very least, it'd be an improvement to not add an inline style by default unless there is an explicit value in one of the Form Editor inputs (like Label Width, Field Width, etc). Alternately, it'd be great to add more inputs to the form editor experience so that the things that are added as inline styles are "open" to be changed similarly to the field width and height (ex. columns have a default margin-bottom of 10px) which works at the issue the other way around without changing the defaults. PROPOSED: ⭐⭐⭐⭐ Update forms2.js to interpret empty values in the forms editor as empty values and do not set inline styles for any elements which are not explicitly entered into an input. ⭐⭐⭐ Update forms2.js to accept a "value + unit" combo (100%, 30em, 400px) rather than just a number appended with "px" for any width-related inputs (including Max Length). ⭐⭐ Add similar inputs (value + unit) into the Form Editor to create user controls for anything that's added as an inline style on any element (ex. margin-bottom on columns, width on inputs, labels and spacers). This would at very least expose the defaults and allow things to be zeroed-out (margin-bottom: 0px) or even better, emptied and then omitted as an inline style all-together.
The current default setting for the Root Block Elements in Email is set to "<p>" and Landing Pages is set to "<div>". This is problematic for folks that are new to Marketo and didn't elect for, or aren't aware of, this setting. 1) It behaves like a "ghost in the machine" whenever a user uses the Rich Text Editor to modify an editable area which can produce unexpected results based on how an email is coded to handle this. 2) <p> elements in email display different from browser to browser and are not an industry standard root block element (<div> would be much better even). This is a functional issue that can "break" email layouts.3) It assumes that content is going to be some kind of text in Email using the <p> element which is problematic for non-text elements inside an editable area -- while assuming that content is going to be some kind of block in Landing Pages using the <div> element which is problematic for text element editable areas (ex. <h1 class="mktoText" id="edit_h1" mktoName="headline 1">...</h1>). Rather than setting the defaults to a value (<p>,<div>) and having the end-user discover this default setting by way of an error (which is perceived to be a Marketo issue b/c it's the OotB default setting), reversing the defaults to "None" would provide a more common-sense starting point and create the perception that the ability to add Root Block Elements is a feature that's built-in and ready-when-you-are rather than something you've got to discover in frustration. PROPOSED: Change the default setting for both EM and LP to "None".
The current default setting for a new form theme is "Simple (1of7)" which adds a layer of styling that most folks end up having to work around in one way or another. The "Plain (7of7)" theme by comparison does not add the additional theme styling and would likely provide a more common-sense default than the Simple theme. A look up of "form styles" in the community finds 5,548 hits to date and it's something I've seen as a gap for most web teams working with embedded forms. The common approach is to kill the Marketo native CSS with a script of some sorts. PROPOSED: Change the default form theme for new forms to be "Plain (7of7)" instead of "Simple (1of7)"
I believe I saw one similar to this in the past, but I have not seen action on it recently. It would be great if we could writing notifications/updates and/or like notifications from the notifications drop down tab. As a whole, I see this tab passed over frequently, and this is the main reason why. People explain that they have to click into the actual notification anyway, so they don't both using their notification tab in Workfront.
Like in other areas of Workfront, it would be helpful if the document view settings would remain between login sessions. My teams uses the List view for most projects and would like for this to remain stick by user choice. Alternatively, if there was a global setting for the documents area where the default view could be set for all users - this would be acceptable as well.
When we routed proofs manually the key stakeholders all had one color of pen they proofed in that no one else could. This made it easy to see who made what comments quickly. Several of my users have requested the possibility to assign particular colors as defaults for particular people. To my knowledge this is not currently possible, but I thought it was a fun idea and wanted to throw it out here!
Currently if a proof has more than one page, we cannot scroll to the additional pages. We have to navigate to the page buttons or change the page number. It would be extremely convenient to be able to scroll between pages without having to navigate to other controls.
The Line Visualisation fails to correctly show the the trend line if the metric is filtered in the freeform table. Example:The date range in the panel is set to Mar 10The metric in the table returns data for the period Mar 4 - Mar 10The line visualisation for any table row returns a value for the day the date range in the table filter starts with (Mar 4) and incorrectly indicated the date on the X-axis (Mar 10) --Another idea related to the Line Visualisation: Fix chart dates when calendar starts with monday
Customer request - The Gnatt chart doesn't align correctly to the tasks if you are Zoom'd in or Out (more or less than 100%). The client would like it to always align regardless of the zoom.Thanks!
I think it would be useful at a reporting and a project/task level to be able to freeze pans, so you can freeze certain rows or columns when viewing information. I chose this for reporting because it would be great to be able to freeze some columns/rows when viewing reports with a large number of columns/rows.
I'd like to be able to save the filters, views and groupings I have set up in a report to appear in the lists for other reports. It would be great if after I created a new report, that I could save the defaults as a new filters/views/groupings in those drop downs. It could be an option at the end of the dropdown next to "Remove" and "New." Something like "Save default"?
Please consider the ability to add custom forms to the Updates area
After configuring a PDF preset, I would like to define shortcuts which lead to the different presets I created.Now there is just the option of saving/exporting a PDF.
I've discovered there is no easy way to track the unengagment with an email. I wanted to see if I could make a smart list of everyone who has not interacted (clicked or opened) with an email in the last 6 months. So for example, I wanted to pull a list of people who did not open any emails in the last 6 months (which seems simple enough). I pull the "Not Opened Email" filter in the smart list. But now the closest pull-down option to include all the sends is "is any" but that will give me anyone who did not open even just a single email, even if they opened all others. So if we could include a 'is every' or 'is all' option it would make my life A LOT easier.
Add the ability to @ mention a user or team from within the Workfront App for Microsoft Teams.
In the Classic Workfront experience, there was a way to attach a custom form to a task without having to fill in the required field information. My agency has project managers add these forms to the appropriate tasks as new requests come up and then another team member fills the form in. Now we're switching people onto the new experience and realizing that all the required fields have to be filled in whenever a form is attached because there isn't a way to add a form without also hitting that requirement.In our scenario, our project managers do not have the information that goes in those forms, they're just the person getting the form in place because they have the proper licenses. Another user with a work license generally has responsibility of filling in the form information and typically at a later date then when the task & form are added to the project.Losing the functionality from the classic experience really hurts the process we had in place. And if the project managers just go in and add a bunch of dummy data to these required fields it means they're going to be triggering any reporting where users relay on these required fields HAVING information to pull into a report so they can count it as having been filled in for processing.
Billing and Cost rate access, within Financial Data, is treated as equal parameters in Workfront.However, in practice cost rates, unless banded, are much more sensitive than billing rates.We would like an option to split the two in the Access Level so we can cater for the following scenarios:As a project manager, I want to set the billing rate of my resources or users, in order to calculate project profitability.As a project manager, I want to review the cost rate of my resources, in order to budget the right resources for my project.As a Finance manager, I want to set the billing and cost rate of my department, in order to calculate chargeable utilisation on projects.As an Account Director, I want to see the billing rate per hour of a resource, in order to provide an estimate to a potential client.The user cases above demonstrate a requirement to separate who in the system can view/edit billing or cost rates,I would recommend adding additional options:View Role Billing RatesEdit Role Billing RatesView User Billing RatesEdit User Billing RatesView Role Cost RatesEdit Role Cost RatesView User Cost RatesEdit User Cost RatesBest,Christian
We are beginning the process of onboarding Groups into the new experience NWE. And, in addition, we're in the process of bringing new Groups into Workfront. These new Groups are being onboarded directly into NWE. Ideally, we'd like to have the ability to change two things in our settings: Have a "New Experience setting directly on User Profiles. So, this way, if we're cloning a user who is assigned to NWE, the assigned interface would transfer to the cloned user. And, if the user is in Classic, vice-versa. It would also be good to bulk edit users in this way.Eventually change the default with NWE from "opt-in" to "opt-out." We're going to be bringing in hundreds of new users and will likely move to auto-provisioning these users utilizing SSO. When a new user has the base-level of access provisioned, we'd like to have that person received into the NWE.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
