🎬 [VIDEO] Top 3 Reasons to use Companies

[CynthiaBoon]

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! 

• First things first – documentation and tutorials! 
  • Create and edit companies 
  • Create companies – short tutorial video 
  • Create and modify a group’s companies 
• Test in the Sandbox first! See what your vision can look like without impacting your live, production environment. 
  • The Adobe Workfront Preview Sandbox Environment 
• Build a Report or a View that lists the impacted objects you want to move. If it’s Users, then a User View/Report. If it’s Projects, then a Project View/Report. If possible, use Groupings to make it easier to organize the work. 
  • Create a basic view 
• Bulk edit or inline edit to assign your new companies. 
  • Edit Projects in bulk 
  • Edit user profiles in bulk 
• Don’t delete anything – just add and test, add and test, until you’re sure that everything works with the new companies. Then, don’t delete – just deactivate. 
  • Deactivate or reactivate a company 

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

[RandyRoberts]

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]

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!

[VynetaRy]

@RandyRoberts   This sounds like the perfect solution to a new Team that I am setting up to manage partner company relationships. I am fairly new to Workfront and having a little trouble wrapping my head around the calculated field part of this. Can you explain the calculations you would have in those fields to pull in the information? I love the idea of prepopulating fields so our customer reps don't have to enter information that already exists.

@CynthiaBoon  thank you so much for the video and discussion. I had been brainstorming a way to handle this and your post made it all click.

[RandyRoberts]

Here's an example where I display the name of the Client Services lead for that client on the Project form, with lot's of screenshots:

First enter a Typeahead field on your Company form that will house the Client Services Lead. I use a dot suffix in the name to identify my Typeahead fields (and I use an underscore for all my calc fields, this makes them easy to identify when they're in a list).

Next is the filter code for the typeahead so it only displays users with the "Client Services" job role. Used the roles:ID for the job role you want to filter for

AND:1:roles:ID=5c9e4f2a00b82d5ae78d319dd7e7de52
AND:1:roles:ID_Mod=in
AND:2:isActive=true
AND:2:isActive_Mod=eq

Then you go through your client list and select the right Client Services person on each client.

Now you add a "Client Services Lead" field of type "Calculated Field" to your Project form.

In the "Calculation" part of the field setup, you enter 

{company}.{DE:YOUR FIELD NAME:name}

with no space before or after the colons. Mine looks like this (note the dot after "Lead"? That's just my naming convention, you don't have to do that)

{company}.{DE:Account Client Services Lead.:name}

The field setup should look something like this

I hope that all makes sense.

You can now add all your staff as well as any other client info you want to pull directly from the client. I have some selectable staff fields as well as the client assigned fields on my project form. A random project in my system looks like this

[VynetaRy]

Thank you! That makes complete sense. I am excited to try this out! 

[RandyRoberts]

I should also add that using a calc field can "bridge the gap" when you want to report on something that's too many hops away.

If I want to know a project owner's manager's name on a document report; that's too many hops. But If I put a calc field on the document's project that lists the owner's manager's name, I can read it from there on the document report.

I just made that up off the top of my head but hopefully you get the gist. Maybe someone can give a better example of the same concept.

[VynetaRy]

@RandyRoberts   Is there a way to reference information in more than one company? For example, if I have a project that is assigned to one company, but there is a different company that also has pertinent information, is there a way to use a value stored in a custom field form to reference an associated company?

I can get {company}.{DE:InfoField} to work, but I can't seem to get {DE:ParentCompany:name}.{DE:InfoField} to work.  For reference, ParentCompany is a Company typeahead field. 

[_Manish_Singh]

Typically, the format is {object}.{field} or simply {field} when referring to the same object. However, the format you're trying to use, {field}.{field}, is not feasible.

[TaraMc2]

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? 

[RandyRoberts]

Putting them in separate companies is a lot more work but it affords you flexibility. All in one Company is easy but rigid and non-flexible. If you ever want to treat one company different than another, like with permissions, layouts, sharing options, etc., you want separate companies

[CynthiaBoon]

Randy, as always, you said it way better (and more succinct) than me! 🤠

[CynthiaBoon]

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!

[TaraMc2]

Thanks Cynthia! I'm on the precipice of a decision now with little time to really scope the build. Here is my use case: 

Current State: We use Outlook inboxes to intake collateral reviews which are then entered into the Workfront tool by an internal user. That internal user resides within the singular company we have today, Bread Financial. 

Future State: We are allowing our external users (clients) to access Workfront to enter collateral reviews as well as track any tasks they may be assigned to. 

• We want to limit their license level to Contributor or Light so task assignment is out of scope 
• We want to be able to provide them with a custom landing page with pertinent request queue types (ex. Collateral Review and Approval)
• We want to limit their visibility to any work outside of their brand 

Considerations: 

• The collateral review and approval workflow they will use to enter their requests currently resides on our current company, Bread Financial (does this mean they cannot have access to this workflow if they sit on their own company?) 
• They will need to work with our internal users (does that mean that our internal users would then need to be on their team?) 
• We use Fusion today to automatically catalog our projects into portfolios and programs based on the brand (client) that they enter on the request screen. We will need to allow access to those portfolios to the external user(s) that reside on that brand (client). If the external user is on a separate company, would they not have access to the portfolio (or do I just share the portfolio across companies?).

I'm really struggling to find best practices and total clarity on when, how and where to use companies vs groups. I really appreciate your insight and any best practices you can impart knowing this use case. 

Thank you! 

[CynthiaBoon]

Ahhh, so if they will be doing "work" via though tasks and requests, then I (just my opinion), would recommend the combination of Companies and Groups.

The short best practice in terms of what Groups are used for is Permissions.  Think of the Group object as like the badge access into a building.  Depending on the Groups a user is in, will determine what part of Workfront they see or don't see.

For example, your Request Queue is a Project that can be shared with a Global Group so that everyone has access, but you would only apply that Group to very specific objects in Workfront.  The good news is that users can be a part of multiple Groups (and multiple Teams) so that they can collaborate across Companies.

The tricky part will definitely be Fusion.  I know you're on a time crunch, but I'd want to make sure that your scenarios don't break.  Portfolio access can be directly shared, but many times is based on inherited permissions, so there might be changes to your process in order to accommodate the additional hierarchies.

For example, if you create new Company, and you want that client to see just their Portfolio, you would most likely would need to change the Portfolio Company to the new one you just created to ensure a "full partition" of projects.  But I believe that will break your Fusion Scenario?  I'm not a Fusion expert, (hopefully you are!), but if you're like me, you might need to "phone a Fusion friend" and get their take on how these changes will affect your Scenarios.  

It's totally worth it, but it will take some effort to break up the original configuration into an expanded footprint.  I know a lot of us had to do it (and I didn't have Fusion to content with), so I don't want to minimize the effort.

[CBuckwal]

When I tested separate company use for a group of external requestors, having the external requestors in a separate company from the main Workfront company, didn't allow the requestor to update on the request to anyone in the main Workfront company. The external requestor could only @mention to those users in their external company. Is there a way to allow users from separate companies to update on a shared object?

[CynthiaBoon]

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.

[CBuckwal]

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.