Skip to main content
Solved

Best practice for maintaining multiple locations for IT Components

  • July 3, 2026
  • 7 replies
  • 91 views
yukselisim

Hello SAP Community,

I have a question regarding how to maintain location information for IT Components.

Some of our IT Components are used or hosted in multiple locations, for example data centers, cloud environments, or office locations. It would be very useful to visualize these locations on a map and also use them in reports. As you know, there is a limitation on the Location field, which can be used for only one location.

I am considering a few possible options, but I am not sure which one is the best practice:

  1. Use the Organization field
    This field is currently hidden for IT Components, and my understanding is that its purpose is to show which organization uses the applications. I am not sure if it is appropriate to use this field for location information, as it may mix location data with application usage.
  2. Add a free-text field under Location
    I could create a text field for locations, but I am concerned that this would be difficult to use consistently in reports and dashboards.
  3. Use Platforms
    Another option could be to create data center or cloud names under Platforms, for example “London DC”, “Azure”, “AWS”, etc. However, I am not sure if this is the right use of the Platform concept.
  4. Create separate IT Components per location
    For example: “X Firewall London Office”, “X Firewall Azure”, “X Firewall AWS”, etc. This could work, but it would take a lot of time and may be difficult to maintain.

I would be very interested to hear your experiences or recommendations.

What is the best way to model IT Components that are related to multiple locations, especially if we want to use this information for maps and reporting?

Thank you in advance for your input.

Best answer by Graham Howe

I have commented on a similar topic previously, but early on with LeanIX we decided to create a new fact sheet type for Locations. This allowed us much more freedom in relationships with all other fact sheets without being restricted to Organisation or the Location field.

7 replies

justinharclerode
Community Manager
Forum|alt.badge.img+1

Great questions. Why not use the organization factsheet subtype region and you can associate multiple ITCs to different locations. For example if you were to setup relations like this:

 

United states (L1) → US-East-NYC (L2) → US-East-NYC-Main Office → Relation to ITC? This is how most customers set up the locations in LX.

 

Benefits 

 

  - A proper named geographic node in the graph

  - Multi-location linking (one IT Component → many Regions)

  - World Map report support (Regions can carry coordinates)

  - Hierarchical geography: Region "London DC" is a child of Region "EMEA"

 

Why you shouldn’t use platforms 

 

 Platform has a specific and narrow purpose that has nothing to do with geography or hosting locations.

 

Platform's intended purpose is to represent a technical foundation or ecosystem that applications are built on top of (example)

think Salesforce Platform, SAP BTP, Microsoft Azure as a development and runtime platform, or an internal microservices platform. The key distinction is that Platform describes what you build or run your software on, not where it physically or logically lives.

No team succeeds without EA.
    yukselisim
    • yukselisim
    • Author
    • Rookie
    • July 7, 2026

    Thank you for the answer. 

    I heard many of the people’s same direction, use the Organization field. 

    My sadness is I will not use the “IT Component Location” report dynamicaly, bacause it relie on the only one “Location” field. 

    I don’t understand the reason why is there are a kind of limitations. What is the logic behind that? Am I missing something?  

    Graham Howe
    Forum|alt.badge.img
    • Graham Howe
    • Royalty For Loyalty
    • Answer
    • July 10, 2026

    I have commented on a similar topic previously, but early on with LeanIX we decided to create a new fact sheet type for Locations. This allowed us much more freedom in relationships with all other fact sheets without being restricted to Organisation or the Location field.

      justinharclerode
      Community Manager
      Forum|alt.badge.img+1

      Thank you for the answer. 

      I heard many of the people’s same direction, use the Organization field. 

      My sadness is I will not use the “IT Component Location” report dynamicaly, bacause it relie on the only one “Location” field. 

      I don’t understand the reason why is there are a kind of limitations. What is the logic behind that? Am I missing something?  

      The logic is that one ITC can only be in one place at one time. So it makes sense to only allow for the location to be tied to one place on one ITC. Who is your customer success manager? I am happy to have them bring this up in your next check-in. 

      No team succeeds without EA.
      Thomas Schreiner
      Forum|alt.badge.img+4

      ​@justinharclerode ​@Graham Howe ​@yukselisim 

      Hi all, let me add my 2 cents here.

      Yes, there is the historical misconception of „1 component = 1 location“. This concept originated from the time when we were not thinking in products yet, but in concrete „installations“ and „hardware assets“. Back then, a lot of organizations had IT Components with locations, some still have them today.

      But later, LeanIX connected components much stronger to the domain of software/hardware/service Products, and even introduced the IT Components catalogue to follow this concept. Companies mostly followed this approach, and those who still need infrastructure assets usually create a new fs type for assets. In the recent years, I have not seen anybody maintaining locations directly on components anymore.

      Thomas Schreiner
      Forum|alt.badge.img+4

      ​@yukselisim Forgot to reference your actual question 😅 It seems like you are talking about specific infrastructure assets here, and not about the rather product-centric ITComponent fact sheet. I would either create a new fs type, or go with ​@Graham Howe ‘s approach to reference them via a separate Location fs.

      yukselisim
      • yukselisim
      • Author
      • Rookie
      • July 23, 2026

      Thank you for the answer. 

      I heard many of the people’s same direction, use the Organization field. 

      My sadness is I will not use the “IT Component Location” report dynamicaly, bacause it relie on the only one “Location” field. 

      I don’t understand the reason why is there are a kind of limitations. What is the logic behind that? Am I missing something?  

      The logic is that one ITC can only be in one place at one time. So it makes sense to only allow for the location to be tied to one place on one ITC. Who is your customer success manager? I am happy to have them bring this up in your next check-in. 

      Justin, I would like to give an example. We have 160 branchs and every branch has same components, such as Palo Alto Firewall, do I have to create location based 160 times which is not be manageble and maintainable, I had started to move with Organization. Create a Palo Alto Firewall IT component with different Organization relationship. 

      I haven’t create any report or anything else, I hope it works :)

      Thank you ​@Thomas Schreiner  ​@Graham Howe  for the suggestions, it seems to make sense to create Location fact sheet but I had started that way. 

      Terms & ConditionsAccessibility statement