Skip Navigation

Best practices for creating an enterprise hierarchy

Consider the following recommendations when planning your implementation:
  • Plan the number of suborganizations and sub enterprises (if you are planning a super enterprise configuration) and how they will be organized.
    • Think about which operators need to send alerts to a group of users. An organization is a group of people that need to be alerted by a specific team of operators and is not always a reflection of the corporate organization structure.
    • Create an organization for each alerting region, such as military base, a campus, or a hospital. The alerting regions are often organized by geography, but can also be organized by purpose such as Weather, Security, or Disaster Relief alerts.
    • Do not make the suborganizations too granular. For example, in a large corporation, create organizations by site, region, or division. Do not create an organization for each department or team.
  • Create end users and operators at the suborganization level, not at the enterprise or super enterprise level. No user accounts should exist in the enterprise or super enterprise organization because it prevents sending alerts to user accounts in the enterprise or super enterprise unless they are enterprise alerts. If users are in a suborganization, they can get alerts from their location as well as any enterprise or super enterprise alerts. You can see all users in suborganizations from the enterprise or super enterprise organization so there is no reason to create any users at this level.
  • Plan the user attributes and alert folders that should be created in the enterprise or super enterprise organization.
    • Use enterprise attributes and alert folders to enforce consistency for all sub enterprises and suborganizations.
    • Think about situations in which you need to alert the entire enterprise or super enterprise. What attributes do you need to target all users in an alert? These attributes should be created at the enterprise or super enterprise level.
    • Attributes that are for only one suborganization should be created at the suborganization level.
    • Do not name a user attribute with the string “Organization.”
      BlackBerry AtHoc
      provides an enterprise user attribute with this name that is used to identify the suborganization in which a user account is created.
  • If you plan to create an organization for “headquarters”, make it a suborganization. The enterprise organization should only be used for managing the suborganizations and should not have user accounts for headquarters personnel. A super enterprise organization should only be used for managing the sub enterprises.
  • Maintain unique email addresses for users across your suborganizations to provide end users with a single enterprise or super enterprise-wide organization code.
  • Enable user uniqueness in the General Settings of the enterprise or super enterprise organization to enforce uniqueness in usernames and mapping IDs across the enterprise or super enterprise organization and all sub enterprise organizations and suborganizations. Having unique users allows you to:
    • Deploy a single desktop app for the enterprise that determines a user's suborganization based on their unique mapping ID.
    • Provide end users with a single Self Service URL that can be used at the suborganization, sub enterprise, enterprise, or super enterprise level.
    • Provide end users with a single enterprise or super enterprise-wide organization code that they can use to sign in to their suborganization client.