Project Number Help

Thanks for the call out Eric, We do indeed have an answer for "just so" project numbering: our UberCalc solution, which does that and then some. That said, for the BASIC type of simple, sequential numbering that Skye identified, I've asked the elves in the workshop to see what we might be able to whip up, for those who simply need that lightest touch. Stay tuned. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

While I understand that may be the case for smaller generation of reference numbers, you should also see that in terms of sequential numbering that it can fail when you've switch to the next thousand generating a lot of reference data across all objects eg let's say in the next month 1809 your reference number is already at 1998. So 1809998 next project could possibly be 1809020 not easy at a quick glance which one was project went ahead first. The only way to possibly make it work to avoid this is to increase the reference numbers to 4-5 depending on the assumption/risk on how often you'd generate more reference numbers. Polly Co

I believe a lot of us are doing that of some sorts - trying to make do with what Workfront currently have. Or for some, looking at other workflow solution that would accommodate this - as they say, for marketing and creative, this is an important number. Most of us believe should be a BASIC in a workflow solution that targets marketing and creative. Polly Co

The numbers are sequential example of the last 8 that have been entered this week (most recent to oldest). There are gaps in the the numbers but they are sequential and you can determine around the time the project was entered by the year and month. AT1808857 AT1808824 AT1808793 LS1808654 PP1808322 VP1808275 PA1808223 UD1808197 Tamara O'Brien Integrated Marketing Communications

It does seem peculiar that Workfront read your request as a rollback of existing functionality rather than a request for something new. Perhaps they simply feel that two unique identifiers (GUID and Reference Number) are plenty for any object, and they don't want to create more overhead with a third one. Lots of different use cases were presented in this thread for identifiers in various forms. (We too had a custom-built project identifier, but we decided to scrap it when we transitioned to Workfront, as we could handle all that information via reporting and custom data fields. The executives needed some persuading, but we are totally accustomed to 7-digit reference numbers now. For us, the number is important only for its uniqueness.) My suggestion for those who want "special" sequential job numbers is to use the API to auto-create your own special brand of job number and then populates it into a custom field. Or perhaps Doug Den Hoed at the AtAppStore already has a solution that can do something like this...? ~Eric Eric Manning Language Line Translation Solutions

Polly/William, Completely agree! Not mutually exclusive. If Workfront were to poll all their marketing/creative companies- I bet 99% of them use job#'s. Might be considered old school, but job#'s are ingrained in how we do business! When we were vetting project management systems- and I asked about job#'s- they said "yes"(which turned out to be the ref ID #) we can do that- and I didn't press any further because it was such a basic functionality that most other project management systems for creatives possess. It NEVER occurred to me press for more details in the sales process. We currently have a work around- but it's NOT ideal by any means. I was extremely disappointed. Just adding my two cents. tks Karen Karen Rutz Harvard: Alumni Affairs & Development

Not discounting what you've done for your instance but I think the main requirement is it's a sequential number. If it's just uniqueness, we would and could just use the current reference number but as there is no real logic to reference numbers as it pertains to a specific object, what we're asking for is a field that is sequential and tied somehow to the project/object. Basic use case, when somebody says 18-4512 in relation to 18-3001, we know that project 18-3001 happened before 18-4512. Can't say the same for 18-ABX235 and 18-4XB128. Polly Co

Our team required unique identifiers for projects and it involved a two letter code that identified the requesting group and the request ID which we wanted to identify the year and month the request was made. With the help of our onboarding consultants we created the following field on our custom form. It takes the requesting group and fills in a two letter tag and combines it with year and month and then just uses the last three numbers that workfront automatically assigns to objects in the system. Field Label: Project ID Format: Text Additional Settings Calculation: CONCAT(RIGHT(YEAR($$NOW),2),if(MONTH($$NOW)<10,"0",""),MONTH($$NOW),RIGHT(Reference Number,3)) IE: UD1802345 New Line Art Accessible Maps I removed all the specifics around our specific requesting groups so you may be able to play with creating a field in your custom form that captures the same data. We just copy and paste that Workfront generated number into project name field so that it is stationary because if you leave it in the custom form...A) its harder to find and B) it isnt static and will change when the month changes. I'd love to chat more if anyone has any questions. Tamara O'Brien Integrated Marketing Communications

I agree, Polly. I didn't interpret the request to roll back the functionality - the existing object-independent Ref ID should remain as is. There should be an additional object-dependent Ref ID created. The two are not mutually exclusive. Very disappointing! William English

We had 55 votes and Workfront said that this is something that they won't roll back now. Their reply: Thank you for your interest in this request. We used to have the numbers generated based on the objects, but we got requests from several customers that it was creating problems due to reference numbers not being unique. The requirement was to have unique reference numbers even within different object types. As a result we changed the logic, so it won't make sense for us to change it back. We apologise for causing inconvenience on your side. I just wonder, 4 years ago, whether the user base has changed. Obviously there's demand from current users that's not being met. They can keep their current reference number but there must be a calculated field that can be attached to reference the specific project object only! Polly Co