I want to hear from you! Which idea is most impor..

[jerflo]

I want to hear from you! Which idea is most important for you and your users?

[K_Donkers]

Thanks for the response. We simply need one consistent number and it does not need any special characters. Our previously tracking system assigned a "job number" and it incremented by one. This number is used by the customer to track their request through the whole process. We are seeing issues with the customer receiving a request reference number in their initial email, which they assume is their final tracking number, but it is different than the reference number for their project. Our Workfront consultant helped us add a field on a custom form that copies the reference number from the request over to the project so we can at least use the search feature if the customer calls or emails us. We have a lot of physicians that simply pick up the phone to call us in between patients and often all they have is their email for reference. The other difficulty is that this copied number is buried in a custom form so our staff are struggling to find it when working on projects. The numbers are growing rapidly in size (our first reference number is in the 22,000s and we are now into the 48,000s) after only 3 weeks. We also use this tracking number for archiving in several current systems. As we implement our new DAM system, the consistent numbering would assist with being able to program for that integration.

[jerflo]

Thanks @Kim Donkers‚‚. After reading, and at a high-level, here is how I understand it based on your needs:

Today

• A request is submitted, it gets ref # 16050.
• The request gets converted to a project and the project now gets ref #16051 (because a new project or "object" was created so it incremented by one). If several other objects are created before the conversion takes place there could be a big gap between these reference numbers.
• You can create a custom calculated field or "job number" to capture and move the original ref #16050 from the request to the project so that you have one number, but essentially you end up with three numbers today (16050/16051/custom job number), even though you are really only referencing one of them.

Ideal Scenario

• A request is submitted, it gets #001
• This request is converted to a project, the project then adopts #001.
• If the request is not converted, the next request is #002, and so on. A project number is not generated; however, if request #002 IS converted to a project then this project adopts this number (002) and so on...

Last two questions:

• Do we need a sequential number for requests/issues or only for projects?
• Do you need to be able to edit or reset this number at any time?

As for the "copied number being buried in a custom form," this is great feedback and is currently on our backlog as an important usability enhancement. I don't yet have a date as to when this would be available, but wanted to acknowledge that we are aware of this.

[K_Donkers]

I believe your ideal scenario describes how we would want this to function. So we would need it for both request and projects. Being that the system requires us to create a request first and before it can become a project, this would be ideal. If we didn't need to create a request first, then that would not be needed. We would need to set the starting point for the numbering one time and then should not need to reset it. We would want to have the number larger than any current number in our archives so they are not confused. For example, our old system ended around 390000. We would ideally like to start there.

[jerflo]

Ah okay, so in your case, you would need to choose the starting point for the auto-generated or sequential number as well. Thanks for the feedback, Kim!

[K_Donkers]

Hi Jeremy, I am wondering if there has been any forward motion on being able to provide a sequential number for tracking of requests/projects. We are only four months into using Workfront and are seeing some issues with the exponential increase in reference numbers which we use to tie the project in Workfront to our archive system. Our archive system requires a consistently formatted number and we may not be able to accommodate the extended field length in our archive system within the near future. We started at 2421 and are currently at 142493 for a reference number. We are eager to get a solution for our issue being that we are launching two more groups in the next month and that will increase our daily submissions of work by customers. Appreciate any insights into potential solutions or new functionality being launched.

[William--]

Kim and gang, if your company hasn't purchased Fusion, I really can't recommend it highly enough. Using Fusion to create custom reference number sequences is going to be more flexible and more powerful than any out-of-the-box enhancement that Workfront might release, because you can tailor your sequences by group, team, or any other attribute; as well sequencing on any object type; not just projects.

I've found that Fusion solves a lot of our Workfront challenges, and depending on the time you can put into it (or budget to have a consultant do it for you), you can get solutions that are better than what Workfront would implement, because you have a higher degree of control over the solution design.

[CalvinFold]

@William English‚, my only objection to this way of thinking is it shouldn't be necessary to spend thousands of dollars more on Fusion to get‚Ķwait for it‚Ķbasic sequential project numbers. Yes, I'm being a little sarcastic, but it's directed at WF and not you. ;-)

Corporations use numbers, lean towards logic. Financial departments especially. Something so basic not being available has made me the recpient of an eyeroll more times than I can count. Heck, I eyerolled when I learned about it; I honestly thought I misread/misheard. It got added to a list of reasons, pre-launch, that we considered for aborting our Workfront deployment. Yeah that list was long enough where we actually had that discussion.

I upvoted an Idea Exchange a long time ago that would seem to cover most needs, be very flexible, and shouldn't be tough to design a UI for:

https://one.workfront.com/s/idea/0870z000000PSAoAAO/detail

Scroll down to my comment for what I think is a fairly robust sequential number handler treated as a special field type.

[K_Donkers]

William -- Thanks for your insights and additional perspective. It is good to know that Fusion may offer some other opportunities we haven't fully explored.

Kevin - I wholeheartedly agree that this should be out of the box functionality and we shouldn't have to pay for another tool to create a custom solution. We were also surprised to learn more details about the numbering once in configuration. We quickly realized it would be a challenge and had some tough conversations too. My old work tracking system had a numbering feature as part of its core functionality and it worked well for us, but the system was at end of life and the company had not provided support for the past couple years. Customization/integrations in our old system made it hard to manage and upgrade over the years so we love the out of the box features of a vended solution. We hope to work more with Workfront on improvements that can help us and other users. I have also upvoted and commented on that post in the past. Thanks!

[William--]

I get it, and trust me, I have a multi-volume manifesto called "Basic Things Workfront Should Do But Doesn't."

That being said, a mindset I would discourage is "we have to spend thousands of dollars just for Workfront to do this one thing that it should already do." That would only be true if you used Fusion to address that singular shortcoming and nothing else.

Instead, I choose to think of it as "we can implement dozens of features and automations in our instance that Workfront could never do for us, because the requirements are so customized to our environment and workflow that they wouldn't be useful to any of their other customers. And it only costs us a little bit more."

In the case of ref num sequencing, Workfront would probably release a feature where each object type has its own running sequence of numbers, and that would be it. It's still going to eventually reach 5 or 6 digits, or flip the odometer and start giving you duplicates. And, that might be okay for a lot of customers, but setting it up in Fusion opens up a ton of possibilities. Your own suggestion for how it should be implemented is a perfect use case for Fusion because you can tailor your serial number in exactly the way that makes sense for your company, but doesn't necessarily work for others.

And Fusion isn't going to do just your project sequencing. It's hypercapable of dozens of similar automations that without it, you wouldn't even consider because they're so labor intensive. (We personally manage tens of thousands of queue topics and routing rules that are generated by custom form values, with hundreds opening and closing each day.) Should Workfront do all of these automations without the extra cost? Sometimes. But a lot of what we throw at it isn't anything that I would ever expect Workfront to develop for us because it's so niche. So if we have it, why not use it to address those things that Workfront should do and just make our teams happy?

For every eyeroll and expression of disbelief I used to get because I had to say "sorry it doesn't do that," I now get a "wow, really?!" (in a good way) when I tell users about a new feature that we've built out to make their time in Workfront more efficient. It makes their life easier, which makes my life easier because I'm no longer the face of something that "can't" but something that "can do that and more."

I don't get anything out of promoting Fusion, I'm just a strong believer that for a little bit extra, it can elevate the performance of any instance. And, when customers use it to solve Workfront's shortcomings in a way that's perfect for them, that feature request becomes one less thing the Workfront development team has to do, so they can prioritize the things that Fusion can't solve - like Chapter 9 of my manifesto, "Custom Field Validation, or the the lack thereof"

[CalvinFold]

Yeah, I had a feeling that would be your response @William English‚ (and to a point, I agree) but‚Ķthat's not how the folks who paid for the software look at it. We tried putting together a list of "things Fusion would solve" and‚Ķthe folks with the money were unimpressed and it got looked at more as a "list of things lacking in Workfront, we can work around them for free or by other means." Given what WF costs, hearing "Fusion solves this" doesn't work in my favor, or WF's. And given what Fusion costs, that pushes it further away.

I do agree to a point, and I'd love to have Fusion as a tool in the toolbox, but others (and to some degree myself) view Fusion as something for integration between separate systems, not as something to work-around features in WF itself that are viewed as "should be included in-box." Especially something as obvious/simple as sequential numbering. Even the most bone-basic would have likely worked (or could have been worked around), but we don't even have that.

As for field validation…yeah, I would love to have even basic grep pattern matching. Seriously, even InDesign can do that…

[William--]

I often forget or don't realize that securing budget in many organizations isn't as easy as just saying "I'd like this, please" to a finance team and then getting it. In that respect, I've been really lucky that my last two employers are generous and flexible when it comes to software budgets. But, that's the minority of companies and it's not usually so easy.

It sounds like Fusion is something you'd like to have if budget could get approved. Presuming it's not already a lost cause in your org (sounds like it might be), my best suggestion is to frame the justification in terms of labor hours saved. Fusion does cost money, but only a fraction of the cost of a single FTE, and with enough automations enabled, it can collectively save more than 40 labor hrs/week (and more!) across an organization. I often run "disposable" scenarios in it because it will do something faster and better than I could ever do in the UI. Another argument for it is that many vendors offer customization or professional services to address feature gaps in their software, but those engagements usually start at six figures and go up from there. In that respect, the added expense of Fusion is not that much.

I guess the reason I advocate for it so strongly is I know from experience how challenging being a Workfront admin can be. It can be really tough! So having found a tool that makes my life (and my user's lives) easier, I can't help but to encourage other admins to do the same for themselves. It's like a software robot that you can program yourself and has the speed and accuracy of a computer. Who wouldn't want that kind of assistance in their daily work routine?

If you ever persuade your org to invest in it, I'd love to share some of the scenarios we've written to help kickstart your usage!

[jerflo]

@Kim Donkers‚ thanks for asking; unfortunately, any and all forward motion on being able to provide a sequential number for tracking of requests/projects has been halted due to other priority initiatives. These priority items have pushed this to the bottom of our backlog. Right now, we have no definitive plan as to if or when we would take this on.

[angielawrence]

@Amy Stella‚ Late to the party, but wanted to throw this out there:

Would the field validations throw errors in Kickstart? Currently we're having to manage macros on our spreadsheet to force these fields into a format we need once in Workfront. But as Workfront doesn't trigger an error for these things, and copy/pasting into the Kickstart doc can override macros, we are left with a potential for error. If the Custom Form has these "rules" in certain fields, it would be awesome if the Import would flag those issues with those fields, so that the user importing the info would catch anything missed on their sweep before it was in the system.

Thanks all!

Angie

[jerflo]

Thanks for your comment, Angie. This is an important consideration. Admittedly, there is still some "TBD" on this feature, but I'm going to include my colleague as well for visibility. CC. @Gevorg Kazaryan‚.

[PatriciaGr]

With the field validation, I would like to also be able to enter "other data" within rules.

Example, for a date field, I would like the ability to enter NA text to indicate the date isn't required. Right now we have to leave it blank. The same would go for numbers.

[jerflo]

@Gevorg Kazaryan‚ FYI, some good feedback from Patricia Greene.