Skip Navigation

Best practices for creating an enterprise hierarchy

Consider the following recommendations when planning your implementation:
  • Plan the number of suborganizations 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 level. No user accounts should exist in the enterprise organization because it prevents sending alerts to user accounts in the enterprise unless they are enterprise alerts. If users are in a suborganization, they can get alerts from their location as well as any enterprise alerts. You can see all users in suborganizations from the 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 organization.
    • Use enterprise attributes and alert folders to enforce consistency for all suborganizations.
    • Think about situations in which you need to alert the entire enterprise. What attributes do you need to target all users in an alert? These attributes should be created at the 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.
  • Maintain unique email addresses for users across your suborganizations to provide end users with a single enterprise-wide organization code.
  • Enable user uniqueness in the General Settings of the enterprise organization to enforce uniqueness in usernames and mapping IDs across the enterprise organization and all 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 or enterprise level.
    • Provide end users with a single enterprise-wide organization code that they can use to sign in to their suborganization client.