Skip to main content

Filter by idea status

10000+ Ideas

Enabling CMYK color codes for proofingNew

Description:Enabling CMYK color code for docs uploading in Proofing environment.Why is this feature important to you:We at Disney use Workfront for request and approval process of both digital and physical designs. We recently noticed the difference in colors in the PDF or JPEG uploaded to WorkFront so we created ticket to Adobe experience league. The issue was identified that we use CMYK color code for our proofs whereas Workfront only supports RGB. The common solution provided to this was to embed the RGB color code to the proof, but we cannot to do that in our case. As mentioned, the documents are used for both digital and physical printing purposes and the print media team only accept CMYK color coded designs.How would you like the feature to work:Our request would be to add the color code to Workfront Proof environment and deviate the color differences. As a developer, I know this is a big ask, but this issue stops the utmost necessity of using Workfront in our company with around more than 1000 users.Current Behaviour:Noticeable color variation in proofsAlternate Solutions:We are happy to hear any other solution for this issue.Timeline:Also, we would love to know if this request is being taken into consideration and the timeline for the change if approved.Attachements:We have attached some samples for reference. Case#00381284 Thanks,Abisheik MS,FileMaker and WorkFront Support,Disney Music Groups.

JeremyNe
JeremyNeLevel 2

New Workfront Home: Greater customization and control for system adminsNew

Description - As a system admin, my team and I really like the look of the new home screen. However we have been reluctant to roll it out because we don't have control over which widgets can appear and the filters and views we use in our dashbord reporting don't translate to the widgets. Giving the group admin greater granular control over the home screen and how it appears (through the use of layout templates) would allow us to lean in and scale this for our users.  Why is this feature important to you - As a system admin we need to be able to efficiently support our users. The ability to control what individual users or use cases see allow us to effectively and efficiently target our support. If end users are able to configure their home screen any which way, support becomes very challenging over a large number of users. Consistency of experience is key.  How would you like the feature to work - I would like the new home screen to be a function of the layout template functionality. I would like to be able to control what widgets our different use cases can pull into their home screen and provide default selections, and leverage existing views and filters. This is not currently the case.  Current Behaviour - You get what you get and you don't get up set. Currently, there is no control over what widgets end users have access to, and the majority of filters and views created and shared are not available. There is also no current functionality for the new home at the layout template level. Additionally, the new home is an enterprise instance level feature. It would be helpful to be able to turn this on and off at the group level. 

Ryan_T
Ryan_TNew Participant

Enhancing Workfront API Integration: Adopting Standard OAuth2 Authorization Code FlowNew

Description - Workfront's API does not use the default standard for OAuth2 Authorization Code Flow. Using out-of-the-box tools available in Integration Platforms or Microsoft Power Platform or other web frameworks is not possible because these solutions expect OAuth2 Authorization Code Flow to use access_token as a Bearer token returned via the and not as sessionID.Why is this feature important to you - There is an increase in development cost and maintenance when creating or connecting third-party apps to Workfront via the Workfront API because of the non-standard OAuth implementation. Limits or even prevents our ability to continue orchestrating and automating work by placing Workfront at the center of our operations.How would you like the feature to work - Ultimately, we would like to be able to use the access_token as part of the Authorization Header as a Bearer token described in the OAuth and standards documentation. This would mean that the token_type be set to Bearer (default, industry standard) and not sessionID (custom Workfront, non-standard) and for subsequent API calls to handle this appropriately.OAuth 2.0 Bearer Token UsageRFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage (ietf.org)Current Behaviour - Workfront’s OAuth API implementation is non-standard, in that once you’ve gone through the usual Authorization Code Flow, the access_token needs to go in the Request Header “sessionID” in each API call. This non-standard approach makes it very difficult and sometimes impossible to integrate with other third-party and custom built applications unless significant time is invested into workaround. In other cases we are left to use a fixed API Key, which isn’t ideal from a security perspective.