Business Applications for different business unit

[Mitch23]

Business Applications have a number of OOTB attributes. What is the recommendation for the same business application used by different departments? Do you append the "Name" (or use a field such as "Business Unit" or "Department" and then have multiple Business Applications

Salesforce - Finance

Salesforce - HR

Or do these represent Application Services (iterations for the Salesforce Business Application).

There is probably guidance somewhere but I am drawing a blank.

Thank you

[Mitch23]

Reading your reply don't you mean if they were truly different instances they would be Business Applications (not Application Services). Salesforce is a business application. We would create business service offerings that could be consumed by the different customer groups

[mcastoe]

No, I do not.   

Application Services are instances of or deployed stacks of a particular Business Application.  there is only one Business Application in this kind of scenario.   Take ServiceNow for instance.   You have your Prod instance and say a UAT and a Dev instance.  You would have 3 Application Services, ServiceNow Platform - Prod, ServiceNow Platform - UAT, ServiceNow Platform Dev and a Single Business Application, ServiceNow.   

Then each Application you license, HR, PPM, APM, etc is also a Business Application set as a Platform App and Platform Host reference set to the ServiceNow Business App.  Each has its own set of Application Services and so forth.

[Kristin1]

I think a good place to start would be to ask yourself why you want to differentiate the department usage. 

If you are looking to represent the system in different portfolios for portfolio management I would suggest creating different Business Application records. 

If you are looking to use this information in a more operational sense it may make more sense to create different Application Service records.  For example, you could have 'Salesforce Finance Prod', 'Salesforce HR Dev', etc.  All of these Application Service records could roll up to a 'parent' Application Service record of 'Salesforce environment' then all of the specific environment records would roll up to the one Salesforce Business Application record.  This would be helpful if you plan on doing a system wide change to Salesforce and you can place the change again the 'Salesforce Prod' record.

Additionally, you may want to consider the 'Subscribed by' related list on the Application Service record if you just want to know impact in an operational sense.

There are a couple of ways to slice it, but you need to know the ultimate goal/reason you want to differentiate by business unit/department/team.

[Barry Kant]

hi all,

I do agree that there isn't necessarily a one-way solution. 

The Design area is a strategic area which is also about invest/divest.

It might be possible that different Business Unit use different Salesforce solutions and the one BU is investing, while the other is divesting. In these scenarios I would create multiple Business Applications. As it is also about having an understanding of the cost of a solution. 

Also when there are multiple ServiceNow solutions, eg:

• ServiceNow for IT
• ServiceNow for OT

If the realised solutions are really different Instances (so 2 platforms) and having 2 BU funding it in my opinion this result in multiple Business Applications. (not mixing up Business Applications Components here , but really the platform level).

BR,

Barry

[Mitch23]

Hi Barry. That was the point I was making to mcastoe in the reply early that each BU might have purchased a separate instance of Salesforce so they would be different business applications. If it is one Salesforce application that is shared among BUs I would agree with Kristin. I will only know once I talk to the EAs, applications owners, service owners.