🎬 [VIDEO] Top 3 Reasons to use Companies | Community
Skip to main content
CynthiaBoon
Adobe Employee
Adobe Employee
May 2, 2024

🎬 [VIDEO] Top 3 Reasons to use Companies

  • May 2, 2024
  • 2 replies
  • 2586 views

We’ve got another Top 3 video with your “On-Demand Workfront CSM”! This time we’re talking about a commonly overlooked (but helpful) object in Workfront – Companies! 

 

Check out the video below. 

 

 

Looking at adding Companies into your mix? Here are some tips! 

Interested in new ideas and approaches? Register for our upcoming workshops our Experience League Events page. We hope to see you soon! 

2 replies

RandyRoberts
Community Advisor
Community Advisor
May 2, 2024

I use companies as clients. I have a different company set up for each product/initiative/MSA-contract, so for us it goes by product or initiative. I attach a form to each "Company" with information about that product/initiative/contract. When a project is opened, the user chooses the product/contract code. Since we are in the pharma/health industry; from that company entry I can prepopulate a lot of the information we need for the project. Example:

Company name is "Humira", from that I know the manufacturer is Abbvie, the therapeutic area is Arthritis/Crohn's/psoriasis, the billing cycle is 60 days, the buyer is Med Affairs, the contact is Jane Doe, the product is pharmaceutical, the product life cycle is post-launch, etc. All this is in calculated fields on the project form that pull from the company form.

This allows the user to not think about filling out a form and concentrate on getting the job done. Plus, it eliminates all the wrong choices you might see in a user-filled form.

CynthiaBoon
Adobe Employee
Adobe Employee
May 3, 2024

Oh wow Randy!  I never thought about using the Company custom form to save time (and ensure accuracy) from any user-filled form. I love Companies for so many reasons, but this is a new one to add to my list. Consider my mind-blown!

 

I know you are told every day that you are awesome, but please consider hearing it one more time.  Thank you!

TaraMc2
Level 2
October 7, 2025

I'm trying to understand if companies are the right approach for an upcoming initiative. Right now, we only use one company and all users reside and work within that company even though they may have uniquely different work. However, we are moving toward allowing our external clients to access the Workfront tool. We want them to be able to enter a request type that currently sits in our global company to begin the review of assets for marketing purposes. We don't want them to be able to see any other information outside of their own work. We have over 200 clients. Would companies make sense in this instance? Should we only have one universal company for all of the clients or should we have 200+ companies? 

CynthiaBoon
Adobe Employee
Adobe Employee
October 7, 2025

Hi Tara!  For me personally, Companies were easier to manage, as I had a similar need (just not as many separate clients).  Will they be doing work within the instance or just opening requests? If they will be doing some kind of work and each client's work needs to be "hidden" then either separate Companies or separate Groups will be needed.  The benefit of using Companies is that users can only be a member of one, so you can group users that way, and then you could have a Group (maybe call it Global Request?) with all users that need to open a request in the "Global Company" so that the Request Queue can be shared with that Group.  

There are several ways to approach it, including using Groups, but if the work really needs to be hidden I'd recommend either Companies or Groups, which means you'd have to create the 200 objects either way. 

I will say one thing about Companies is that it makes the reporting easier to filter.  I will also say, that regardless of which way you go, definitely build a "cross-functional" custom form attached at the Project level so that you can tag Projects with specific initiatives or specific campaigns that cut across your Companies or Groups.  That way, you can build some nifty reports that can cut across any organizational structure (Companies, Portfolios, Programs, etc.), and still see any project in that "initiative" or "campaign." 

Since you have so many clients, if it were me, I'd probably test the changes in the Sandbox first.  Pick a user from one of the clients, lock down their access using the Access Levels (from the screenshot below), and start removing permissions from objects, and then login as them to see what they see.  Then create a test Company, and see if that's a bit easier. That's a lot of clients/users, so I'm hoping one way is way easier to build and maintain than the other!

Level 4
October 8, 2025

So, they can update the request, but they can't tag other users, right?  That might be a setting in the Access Level? You might try checking to see if some of these are locked down, and test if unchecking them gets you where you need.

If there's not an issue that users from different Companies can see other users, you don't necessarily have to hide the users.  But I understand in cases where competitors might exist in the same instance.   In that case, I'd probably create a cross-functional team that includes all of the folks that would need to communicate with each other, and tag them in updates.

 

 


No matter which combination that I test, users from different companies can't tag each other in a shared object update. I tried adding different company users to the same group and removed the company access restrictions and that didn't help.

Are groups and teams supposed to override the company permissions? Are users in different companies supposed to be able to update each other on a shared object if the settings are correct?  I'm not sure what I'm missing here.