Skip to Content

Part 1: Understanding SAP CP Global Accounts and Sub-Accounts and what this concept means to corporate SAP CP architectures

This is part 1 of my blog series about cloud architecture with SAP Cloud Platform. Find the series overview here.

I chose to start this blog series with an explanation about SAP CP Global Accounts and Sub-Accounts. To me, it’s one of the first things you should think about when introducing SAP CP at a customer. This task corresponds to the landscape planning that you typically do for an on-premise landscape so the architectural design decisions you make here are quite fundamental. I also observed that not many people know about these concepts because many only have experience with the SAP CP Trial Accounts, which do not make the underlying SAP CP account structure visible to the user. At real customers, of course you must not use Trial Accounts productively, especially for legal and support reasons! 🙂

So let’s get started. When I first approached the account topic I was quite confused, but the following figure that was created by my colleagues from product management (I don’t know who it was, but thanks to you, good job!) really helped me in understanding and explaining the concept:

You see that in this picture, three sub-accounts are structured in one Global Account. So what’s a Global Account then?

Basically, when a customer decides to purchase a productive SAP CP “account” (and in this case, “account” is technically not the correct term, one could better say “when a customer decides to sign a SAP CP contract” (which is of course in the productive landscape)), then the customer receives a Global Account.

All metrics like quota and resources, or amount of Java Compute Units, even billing, is done for this Global Account. A Global Account is always associated with one datacenter (UPDATE 2018-08: Global Accounts can now span accross multiple datacenters/regions.). This is the first thing you have to consider: Where do I actually need my Global Account to run? Compliance reasons, for example, might quickly answer this question for you.

Moving on, a Global Account is more or less just an empty shell. You cannot do much with it apart from looking at your overall resource consumption. You cannot run applications or services directly in a Global Account. For these tasks, you’ll actually need Sub-Accounts. (Just as a remark: when you sign up for a trial account, what you receive a dedicated Sub-Account. You have no direct control over the trial landscapes’ Global Accounts).

As you can also guess from the above picture, a Global Account can host many Sub-Accounts. This is what a typical Global Account at a customer could look like (here we have six Sub-Accounts):

You can create new Sub-Accounts in the Cockpit easily with the “New Account” button on the top of the screen:

In order to understand and be able to plan how many Sub-Accounts you might need for your SAP CP project(s), first we have to understand what a Sub-Account actually is.

When I explain the concept of a Sub-Account to a customer, I typically compare the Sub-Account with an on-premise NetWeaver system that is now in the cloud (this is not a perfect definition as such but in my experience, many customers understand the similarities and concepts when I explained it like this).

A Sub-Account

  • Can host different applications simultaneously (Java, HTML5, and XS)
  • Can have zero to many database systems connected to it (you could even share database systems between Sub-Accounts to some extent, please consider the documentation for this)
  • Has at least one trust configuration (the configuration where you maintain users, groups, roles, … (there will be another blog in the future for this)
  • Has one or more SAP Cloud Connector(s) connected to it
  • Has a set of destinations (to on-prem or internet systems) that you can maintain and that all applications in that Sub-Account can consume and share
  • Has ONE dedicated area where you maintain the administrators and developers for this Sub-Account (these users are called “Members” on HCP)
  • Has zero to many Java Compute Units to host Java applications
  • Has a git repository service where you can host many repositories for different projects
  • Has other HCP Services assigned to it that can be configured and used differently for each Sub-Account

This is what the configuration start page for a Sub-Account in SAP Cloud Platform looks like (“Cockpit”):

This page should look familiar to everyone who has experience with the SAP CP Trial Account. In productive environments however, you’ll notice that you can switch between different Global Accounts and Sub-Accounts in the upper center area of the screen.

From an architectural perspective and in order to plan the “Cloud Landscape”, I would at least consider the following questions:

  • Do I need more than one Global Account?
  • In which landscape should I host my Global Account(s)?
  • How many Sub-Accounts do I need? When does it make sense to have more than one Sub-Account?
  • Should I host multiple projects in one Sub-Account? To what extent do I want to share configurations and services between projects/development teams in my Sub-Accounts?

Of course, all these questions can be answered differently for each customer. So my recommendations are just my experience which you might not agree to. Also, these recommendations could also change if certain features of SAP CP are changed in the future (which is definitely possible in the rapidly changing cloud world today).

  • If you want to transport an application between DEV, QA, and PRD for staged application development, it might make sense to have three Sub-Accounts so you can transport between the Accounts (I will release another blog that deals with transporting)
  • If you have completely different scenarios, it might make sense to distribute the scenarios/projects across different Sub-Accounts because it will make your configuration a lot easier (side-effects, access restrictions, …)
  • If you have different development teams working on your projects, I would assign different Sub-Accounts to the teams so that they do not influence each other
  • If you need different trust configurations for each Sub-Account (one for example using SAP Cloud Identity Service as a user store and another only an internal Active Directory), it might make sense to create individual Sub-Accounts with different configurations
  • If your applications and the administrative access to these applications (developers, administrators, and support users) have to be restricted, it might make sense to have separate “high-security” accounts. You assign the “Members” of each account (like developers, administrators, and support users) individually to each Sub-Account. Also the backend systems that are available to your cloud applications are exposed separately per Sub-Account. With separate Sub-Accounts, you have more control over the access to your backend systems.
  • Data security requirements and compliance rules will tell you whether you need more than one Global Account and also where to host your Global Account(s). Also network latency reasons might influence your decision concerning the datacenter.

You see that there are many reasons to introduce many Sub-Accounts in your cloud landscape. But there are also reasons to not always have separate Sub-Accounts for each project/application:

  • HANA Database systems are assigned to one Sub-Account and sharing them, although technically possible to some extent, might cause confusion and unwanted complexity in the landscape. Although you can consume the DB services (e.g. xsjs OData services) from other accounts in HTML5 web-applications (with Java applications it’s a different story), the maintenance and database administration is accessible from one Sub-Account. So if you have multiple similar projects sharing the same developers, same application architecture, and same database, why not gather them in one Sub-Account?
  • Configurations have to be made individually for each Sub-Accounts. If you have many Sub-Accounts, this means more configuration work for your administrators (or less, if it makes your life easier when separating multiple projects on one Sub-Account)
  • Connections to on-premise systems have to be made separately for each Sub-Account. Although you can copy the settings, still, you’ll have to maintain them separately. On the other hand, it’s easier to just shut-down all integration paths for one project when you just have to delete all integrations to one Sub-Account on the Cloud Connector.

In general, I would argue that there are many good arguments to make frequent use of the feature of creating new accounts. You can even create new accounts via the command line so you could automatize the creation (which could be a really cool feature if one of your customers orders a development environment for a new project in the customer’s internal shop system and automatically, a new account was created for that project team… 🙂 ).

An additional topic that I do not want to cover in all detail but that nevertheless should be considered is the structure of your HANA databases in the cloud. Since there is the concept of Multitenant Database Containers (MDC), you can basically use a database system to host multiple independent HANA databases. Independent in that case means that although the databases share the same “physical” machine (= resources) and also the same HANA revision (important restriction!!), they have completely independent configurations, user management, and database content. Since not that long ago, you can also share database systems between accounts, so that you potentially can use the same HANA database system in multiple Sub-Accounts where each Sub-Account has an independent HANA database connected to it. With this, SAP is adding a lot more possibilities to landscape design and SAP CP subscription cost (distribution between projects), but I really want to cover this later as I think for now, you’ll probably have enough information already to digest.

Summing up what we covered already, I just would argue that it really makes sense to put some effort in proper Global Account / Sub-Account planning. Involve also management in those discussions and find out how they plan to extend the SAP CP landscape in the future. This might give you good guidance of how you have to plan your landscapes because your decision may significantly influence subscription costs and extensibility of your future SAP CP landscape.

Feel free to contact my SAP colleagues or me if you need advice for your projects! Let me know whether you have learned something in this blog or if you have questions!

Cheers, Jakob

For further information, please consult the official documentation. I recommend the following pages:

You must be Logged on to comment or reply to a post.
  • Thanks Jakob, nice blog. Most customers will probably go for 1 sub-account for each back-end environment, but they should consider the options carefully. I'm a big fan of having a 'pre-prod' environment but it only really makes sense if you have a back-end pre-prod too.

    The new option to set specific versions for each app on the launchpad does make the single sub account option slightly more feasible I guess. Wouldn't be my choice though

    • Hi Mike, thanks for your comment. Yes, you are right but some of my customers do not use the launchpad. Others might have different trust configurations (especially because group names can differ between environments, so you have different group names between dev, test, and prd), so in those cases, it's much 'cleaner' with separate Sub-Accounts. Cheers, Jakob

  • Perfect timing as the question of subaccounts and managing different tiers just came up for one of the customers I work with.  Your blog covers the topic rather well and more clearly than the help docs I usually have to work with.

    Greatly appreciate your efforts and presentation of a sometimes confusing topic.

    Cheers, Mike (Moderator)
    SAP Technology RIG

  • Hi Jakob,

    if I understood it right if a customer has two or more Global Accounts his data are in different datacenters / geographies. Is there a kind of replication availabale or a kind of data hub? Otherwise I would loose (in my opinion) exactly what f.i. S/4 HANA with one common datastore (no more distributed data in different ERPs, CRMs, SRMs and so on) promises and I would need a kind of “Cloud-BW” to do for example reporting or planning for a globally operating company.


    • Hi Michael,
      for those kinds of integration scenarios, I would strongly suggest you familiarize yourself with the following topics:
      - HCP Integration Services (previously known as HCI)
      - SDI and SDA
      - API Management on HCP
      Probably, with these services or tools you can still "synchronize" your data depending on your use case.
      Additionally, I would also recommend you to familiarize yourself with the intended use cases for HCP. I think the examples you mentioned are not really the use cases where HCP fits (or I did not understand your examples, sorry if that is the case!). S/4 Cloud Edition or HEC (where you'd have ERP, CRM, ...) might have different solutions for your multiple geographies issue... I am not an expert on these topics. For HCP however, I can tell you that the geography "restriction" actually has many benefits when it comes to compliance questions ("European data has to reside in European datacenters...") and from my experience, SAP has quite many integration, virtualization, replication, and synchronization solutions that you could use. I'd be confident that something in the portfolio fits your requirements here.
      Cheers, Jakob

    • Hi Michael,

      For the replication of data based on your requirement as Jakob suggested you can use other solutions from SAP. Ex. HCI DS.

      The major reasons for multiple global accounts are:

      1. Data privacy: If the customer has business in different parts of the world and it is important to keep data in respective country or continent of business multiple global accounts are suggested.
      2. Latency Issues: If the users of the app are from different continents like USA and Europe, considering latency issues it make sense to have 2 global accounts - one in USA and other in Europe.
      3. Other business/development reasons: If the company is a large conglomerate, they can have multiple global accounts because businesses or entities are independent to each other.

      Note that customer has to sign multiple contracts to have multiple global account.


      Midhun VP

      SAP Cloud Platform Customer Success Team


  • Hi  Jacob,

    Good blog on Cloud accounts in HCP.

    If I am using the HCP services like IoT service, Can I configure the services for each sub account?

    Once I have configured the IoT service in Sub-account1, the service doesn't even show up in Services area of Sub-Account2.




    • Former Member

      You will have only one instance of these services: IOT, Compute Unit, Virtual Machine and HANA DB and Custom Domain. That’s why you are not able to see IOT in your second sub account.



      Midhun VP

      SAP Cloud Platform Customer Success Team


  • Great Blog Jakob!

    I have a question. When I  rename a existing Sub Account in Cockpit, changes are not reflected in Hana Cloud Connector. Why is that and how to fix it? I tried to Disconnect and Connect again, but still it reflects the old Name.






    • Hi Bidwan,

      thank you for pointing this out.

      I suspect the Cloud Connector resolves the unique account id (from the at the time you enter the sub-account's name when connecting the SCC to a new Sub-Account. Once the connection is established, I suppose the Cloud Connector only uses the id and not the name anymore. Probably, you should open a ticket to report the missing update mechanism for the Sub-Account name.

      Best regards,


    • while configuring your sap cp account with Cloud connector you only give

  • Hi Jakob, this is really a great blog - and I would like to see more on the same topic.

    With an SCP landscape consisting of several sandbox/dev tenants, admin rights are (at least in my case) distributed to several users. Is there a way for admins of the main account to limit the feature of creating more sub accounts without revoking admin rights? It would be quite useful to let someone be admins to an account but without the ability to create more sub-accounts.

    Another thing on my wishlist is the ability to see which users created sub-accounts and for me, as an admin of the main, global account, to access all sub-accounts.

    Maybe others have encountered the same issues - so please comment 🙂


    Kind regards,

    @simenhuuse /Simen

    • Hi Simen,

      I fully agree to your remarks, such functionality would be very useful. Currently, the permission to create new Sub-Accounts cannot be taken away from administrators. From the current roadmap slides, you can see that there might be a new feature that allows building your own "Global Account Roles". This could be a way to solve it, but I currently don't know whether there will be an explicit permission to create Sub-Accounts.

      What you can do is execute the "list-accounts" command from the console client. This will give you a list of Sub-Accounts from your Global Account. When I last tested it, this command gave ALL Sub-Accounts in your Global Account and not only the ones your user has member privileges on. So with this, you could monitor whether users create their own Sub-Accounts without permission.

      Who created the Sub-Account will only be visible in the Member History of a Sub-Account however. The creation time is listed in the Cloud Cockpit or the "list-accounts"-command-output.

      Kind regards,


  • Hi Jakob. Regarding the following comment, where can I found more information about transporting between accounts?

    • If you want to transport an application between DEV, QA, and PRD for staged application development, it might make sense to have three Sub-Accounts so you can transport between the Accounts (I will release another blog that deals with transporting)

    Thanks in advance!


    • Hi Andrés,

      I will write a blog about this, writing is currently in progress. If you want to find more information already, search for "MTA", "Solutions", "CTS+", "Solution Manager with Cloud Platform" or similar...

      Depending on your scenario, there are different methods that might be feasible, so stay tuned for the upcoming blog.

      Kind regards,


  • Hi Jakob, in my experience some services do port nicely across accounts whereas some do not (HANA for example) ... have we got an illustration, or even a list that defines which services suit being moved across accounts and those that do not? Typically for three tier environments (dev, qa prod)

    • Hi Joshua,

      sadly, I am unaware of the existence of such a list. But creating it is a great idea! Maybe that would serve as good content for the next blog 🙂

      Best regards, Jakob

      • If you could work on that it would be great .... the majority of queries I get in the UK is about cloud administration as much as it is capability and security. Thanks for the response. Josh


  • Excellent and Simple way of explanation for such a havoc topic.

    Thanks and please continue this really helpful series fo waanabe Cloud Architects like me. 🙂

  • Hi Jakob,

    excellent post. I stopped at one item:

    If you need different trust configurations for each Sub-Account (one for example using SAP Cloud Identity Service as a user store and another only an internal Active Directory), it might make sense to create individual Sub-Accounts with different configurations

    It means that if I need to connect each sub-account to an Authentication Service I need a different Tenant ID for each one?

    I asked that because I already connected an Production AS Java to a PRD enviroment, and I went to do the same from an Quality AS Java to a QAS sub-account but cannot find the right steps to clone it from the same Tenant ID.


    Thanks a lot for your help.

    • Hello Andreas,

      The SAP Cloud Platform uses external user stores for applications deployed and running on it, like for example the user store of the SAP Cloud Platform Identity Authentication service.

      The trust configuration is performed on subaccount level and this way one and the same SAML IDP (the default trusted IDP) is used for authenticating the users for all applications deployed and running in that subaccount.

      When you have several subaccounts for managing the lifecycle of your apps (DEV, QUA, PROD), you can configure one and the same trusted identity provider for all your subaccounts but you can also configure different IDPs. If you have, for example, a separate Identity Authentication tenant for test purposes, you can configure it as a trusted Identity Provider for the subaccounts dedicated for development and quality activities and to configure the productive Identity Authentication tenant only for the PROD subaccount(s).

      By the way, using the SAP Cloud Platform Identity Provisioning service, you can provision easily users from one tenant of the Identity Authentication service, to another or from an MS Active Directory to the Identity Authentication tenants using some rules, for example group membership.

      With the SAML technology there are two authentication scenarios – SP initiated (Service Provider initiated) and IDP initiated (Identity Provider initiated). You can play with these configurations on the Identity Provider side when you want to keep two applications into one and the same SAP Cloud Platform subaccount but to use for them different trusted Identity Providers.

      The rule is that always the default configured trusted SAML IDP will be used for all SP initiated calls for all applications running in the subaccount.

      When a different SAML IDP has to be used for any of the apps in this subaccount, the respective SAML IDP must be configured as trusted for the subaccount and on the IDP side you have to configure IDP initiated calls that will lead to respective application. If you are using Identity Authentication service, you can read here how to configure IDP initiated authentication .

      Kind regards,

      Donka Dimitrova

  • Hello Jakob

    thanks a lot for the very good explanations and your detailed blog about the global accounts/sub-accounts in the SAP Cloud Platform (SCP).  At a customer I have the challenge to propose an architecture setup for accounts/sub-accounts in a setting where we have not only system stages (DEV, QA, PROD) but as well different organization units that want to develop and engage with the SCP (e.g. Retail, Production, Procurement, etc.). The company currently acts only on one continent hence the necessity for multiple global accounts due to geographical business distribution is not given.

    You have listed the picture of a global account which includes sub-accounts for DEV, QA and PROD. The different org units now are an additional modeling level on top of DEV, QA, PROD and hence my question to you (or ask for professional advice) how you would model this multi-level concept of multiple stages and multiple org units? Is there any best practice already available?

    I came up so far with two possible solutions:

    A) One global account - many sub-accounts

    Having one global account (for entire company) and hence every org unit has itself a DEV, QA and PROD sub-account using e.g. naming conventions like DEV_Production, QA_Production, PROD_Production.

    Transportation mechanism in such a setup would be simplified and also user control/access mgmt is much easier to my understanding in that setup.


    B) Multiple global accounts - each 3 sub-accounts

    Having multiple global accounts (for every org unit one) and inside the global accounts DEV, QA and PROD sub-accounts.

    Transport mechanisms between different org units still have to be clarified (from global account to global account) but maybe you already wrote a blog as well about transportation mechanisms in SCP inside a global account and over multiple global accounts?

    From a license point of view I see as well some challenges here.

    What are your comments to the two approaches? Can you recommend something or do you even think that solution B could lead to problems in the future? What does SAP propose or maybe develop to conquer the configuration nightmare in the future that might arise in an SCP setup with one global account and many sub-accounts (where # sub-accounts is e.g. > 10)?

    Thanks a lot.



    • Hi Andreas,

      both your suggestions are valid from a technical perspective. For transporting, there are no additional limitations in a scenario B.

      However, as you correctly assumed, licensing and organizational questions are the main drivers for the decision for or against a scenario (Depending on the type of applications you want to realize it might even be necessary to have multiple global accounts). Main factors I see influencing that decision:

      • Multiple geographies (not relevant for your scenario it seems)
      • Having multiple global accounts will make it more difficult to "share" resources between organizations. Let's assume the HR department does not need "their" resources anymore and the Production department wants to use it. If you have multiple global accounts (so you also have multiple contracts), this might give you organizational issues. Technical, the limitations are minimal, with the exception that the Cloud Cockpit will be less easy to use because you have to switch between global accounts while navigating.
      • Having multiple accounts (and therefore multiple contracts) might be easier or more difficult from a billing and resource consumption perspective depending on your customer's complexity. Resources such as API requests or Portal usage are measured and billed on global account level. So in a scenario with only one global account, the departments might be "competing" for the resources which might (or might not) lead to "internal trouble" and additional alignment/controlling.

      As you see, the answer depends very much on your customer's preferences and complexity. The technical implications are neglectable from how I understand your scenario at the moment. If your scenario involves the Identity Authentication Service, you might want to prefer scenario A because of the tenant model that comes with the service.

      Additionally, I would like to disagree with your perception of a "configuration nightmare" if the number of subaccounts is increasing. My "typical" customers have a few dozen subaccounts and I have seen some which have more than 100. If you have a good operation model and proper architecture/team setup, I have always perceived the notion of subaccounts as a blessing and not a nightmare because of the proper separation that can be achieved!

      Hope that helps!

      Best regards,


  • Hi Jakob,

    I see that this was updated to refer to global accounts covering multiple data centers:

    UPDATE 2018-08: Global Accounts can now span accross multiple datacenters/regions.

    Do you have any further information on this? Because I can’t seem to locate an announcement or other post covering this (very welcome) new development. I see that the account page has been redesigned and it does show “1 Region” now but could you perhaps update this post to point to any other resources covering this? I’ve found this help page on the Regions concept and it appears that Subaccounts are now region-specific? I seem to be able to create new subaccounts in a region of my choice, though I’m wondering if it would affect my billing.


    Kind regards,


    • Hi Tom,

      I suggest you look at the Planning Guide for SAP CP ( into the chapter "SAP Cloud Platform Account Model"... this explains it rather well. You have understood correctly that a subaccount is always associated with ONE specific region, but it could be that your global account addresses several regions as can be read in the Planning Guide.

      Please understand that I don't know about your specific contract so I don't want to comment on billing questions here...

      Hope that still helps!

      Kind regards,


      • Hi Jakob,

        Just realised I never replied to you so just wanted to say thanks for pointing me in the right direction. We've since clarified the account model and IIRC the multi-region support was also pushed as a notification in SCP at the time.

        Of course I understand that you can't comment on contract questions, no worries there, this was still very helpful.

        Kind regards,


  • Hi Jakob,

    If multiple global accounts have been created accidentally, is it possible to consolidate them?
    Is it possible to transfer a subaccount from one global account to a different one?

    Kind regards,


    • Hi Stefan,

      your options highly depend on your current contract situation, so I cannot give a generic answer to that. I recommend you talk to your Sales Executive or SAP CP Customer Engagement Executive if available.

      However, I also suggest you consider why you actually want to "merge" the global accounts. If it is "only" for "beautification" reasons, maybe don't bother with it and wait until your current contract is about to be renewed. Then would be a good point in time for the merge. If there is a real functional benefit that you want to draw out of the merge, please elaborate further. Oftentimes, a "merge" is not necessary to realize a certain scenario/requirement...

      Kind regards,


  • Hi Jakob,

    We have provider model application. It means sub-account A is the provider and sub-account B is the consumer account which is accessible to the customer, customer will not have access to the sub-account A. Now customer can only connect cloud connector to the consumer account "B". But the CPI service is running in provider account "A". How can I access the cloud connector of consumer account "B" in the CPI service. Is there a way to access cloud connector configuration in the provider account?

    Kindly help.



    • Hello Yatendra,

      If I understood you correctly, you want to access a Destination in Subaccount B (pointing to a backend system via the Cloud Connector) from the CPI in Subaccount A.

      From my perspective, the best way to do this would be via an API (API Management) or a CPI tenant in Subaccount B. You could also develop a proxy in Subaccount B and integrate it with the CPI from Subaccount A. In all cases, you have to take care for proper security measures. Especially if you develop something by yourself, you could for example secure the proxy with OAuth or similar.

      Hope that helps!

      Best regards,


  • Hi Jakob,


    Thanks for a great blog, it will be helpful in making customers understand the sub-account concept.


    I have a question related to getting started on using SAP CP services. Client knows they have license for services, but not sure who is the owner of global account. Will the global account access provided to a individual S-user ID or a new S-user ID be provided as part of licensing.




  • Dear Jakob,


    first of all, thank you for your attempt to bring a little bit more order to this “chaos”, as there are unfortunately several official ressources around that are contradicting each other, where one is saying that the Global Account is region-independent,



    and another one saying, that the Global Account has a region (cf. CP100_EN_Col06).



    How for I understand it (please correct me if I am wrong), the “Regional” nature of the Global Account has no

    • Performance aspect, as the data is not stored at the G. A. level, but on the Sub-Account level
    • not “fully” fullfilling Legal or Data Security Requirements: Ok, the Global Account is a contract, so there is a legal component, but, technically, there is no obstacle in creating several Sub-Accounts that are assigned to different regions, the customer may avoid. For instance: If I have a German Customer, that only wants its data to be stored in Germany, for e.g. St. Leon-Rot, and he creates the Global Account “there”, he could, even by accident, create several Sub-Accounts that are then hosted on Data Centers anywhere. The Sub-Accounts of a given global Account are not “nailed” to the  region of the Global Account. Or are they? Is there a mechanisms that would trigger an addition to the contract, or a required “extension” to the regions of the Sub-Accounts that are in regions different to the one of the Global Account?

    “Data security requirements and compliance rules will tell you whether you need more than one Global Account and also where to host your Global Account(s). Also network latency reasons might influence your decision concerning the datacenter.”

    I guess one source of the contradiction is that the ressources are not distinguishing between “de-facto” and “de-jure”. A contract is for sure legally binding and has a regional nature, but if it is still technically possible (if it is not possible, then I did not had the information and I excuse myself hereby 😉 !) to create a Sub-Account in a different region, then..


    Thanks & Best reagrds,


  • First of all Thank you! Excellent presentation Jacob and explained in simple way to understand better.


    I have a question related to sub accounts and systems connectivity?  under one sub account, at the same time, can we connect using Cloud Connector , two Gateway systems (one for Project Dev  (Ex: PD2- Systems id) & another for (Ex: BAU Dev – AD2- Systems id ) is it possible?  Please help me on this?

    And also how does pricing work for Global Account / Sub Account? and validity of account?