Skip to main content

Filter by idea status

10000+ Ideas

BrendanO_Level 2

New Proof Version Approver RolesNew

I understand that there have ben changes in Workfront recently that relate to this suggestiuon, but I am unclear what the current status of this feature should be.At the moment, when a new proof version is created, all the roles from the previous proof are copied across. Workfront Support advise that this is the designed process; nothing to fix.I suspect that this feature works for some businesses and not for others. Rather than having 'one or the other' why not build in an 'option' within 'WF Proof > Account Settings', such that each business can choose whether they want the roles to be maintained, or not.Our business routinely uses the following process‚Ķ Proof Version 1 1. Designers create proof and add Moderator2. Moderator reviews proof to determine decisiona. If no additional decision maker is required, then Moderator simply applies their decisionb. If Moderator is happy with proof, but additional decision makers are required, then Moderator adds ‚ÄòReviewer & Approver’3. ‚ÄòReviewer & Approver’ may decide proof is not ready and another proof version will be required based on their decision. Proof Version 2 1. All the same steps, above, except that the additional decision makers may be different, subject to availability.2. Additional decision makers should NOT have the proof shared with them until the ‚ÄòModerator’ has had time to assess the new proof, as per the steps above.

Add additional usage data for bulk API queriesNew

When setting up software to interface with Marketo's REST API, especially the bulk API, users are limited to understanding what API manipulation they have within their control—the calls and jobs they themselves have made and can poll. However, this view completely misses any other action other accounts may be using. What I'd like to see is a set of additional features around stats and usage, including:   1. The ability to see how many bulk jobs are queued: right now, you can only manage the amount of bulk jobs your process has created, but there's no way to see what other bulk jobs are running in parallel. I'm thinking of something as straightforward as an API call that lists the current number of bulk jobs being processed. Major bonus points if the call can also give an expected ETA when the next job that will complete first will end. This way, bulk jobs can be scheduled more effectively rather than checking existing jobs continuously.    2. The ability to see how much bulk data has been passed: while subscriptions can have varying bulk data limits for the day, knowing if your API process or if others took up the entire import/export daily limits is difficult. If there was some way to check against the same mechanism that limits data, this would help developers make smarter decisions on how much data to import/export and when it makes the most sense to do so. Alternatively, this can help ensure there's a buffer of bulk data available for other processes.    3.  When using any bulk job status API endpoint, having a (very rough!) estimate of when the job is anticipated to complete returned would be great. Queuing multiple jobs means the estimate you'd have for one job completing may not be accurate, and even knowing within a five-minute window when a job is anticipated to complete helps with properly queuing subsequent jobs.