This section explains the additional planning issues you need to consider when creating an implementation of the driver that is like the sample workforce tree configuration provided. (See Workforce Tree Configuration.)
This number is entered in the work order as the ObjectID attribute, and you can use a custom style sheet to cause Identity Manager to match the work order with the corresponding user.
The sample workforce tree configuration provided uses the eDirectory Workforce ID for the User object, but you could use the employee ID, or some other number that is used in your organization, such as Social Security number. This number must be stored as an attribute of the user object so the driver can find it.
Because this number is stored in the PBX in the Cable field, it can be only 5 digits long.
Keep in mind that this ID must also be entered in the work order for any work orders entered manually or in a work order database.
When you are planning how to determine which PBX to configure the user's extension in, it's important to understand how the PBX sites are configured. A PBX cabinet can be configured as a remote cabinet, meaning that it is controlled by a master PBX but is at a different office or even in a different city. This can mean that a user location in Human Resources might not have a simple mapping to a PBX site and location within the PBX system. which can so that a single PBX site might be comprised of cabinets at more than one campus.
You'll need to determine what business rules to follow. For example, you could customize the style sheets to assign non-DID extensions to users who work in a call center, based on job title.
It is not necessary to have a DID and non-DID range. If only one range is needed, you must use the DID range. You can, however, still use two ranges if desired.
The phone type must be assigned by the style sheets automatically, based on business rules about user information such as job title. For example, you could specify that users with the job title of Administrative Assistant receive the phone type 83424.
You could set restrictions on time of day usage, long distance calls, and international calls based on business rules and attributes of the user. For example, you could use criteria such as job title, or the user object's placement in the tree.
The sample configuration demonstrates automated responses for certain user events, such as updating the display name in the PBX when the name of a user changes.
This kind of an effort would be largely manual, but you might be able to do some automation by creating custom tools to compare existing user information with information in the PBX. You can get a list of what exists in the PBX using the Migrate into NDS feature. See Managing Existing Users.
The Avaya PBX driver can manage new users. It can also manage existing users.
Determine what information from a user object you want the style sheets to use when creating the display name.
The driver does not require entities that have phone numbers to be represented in eDirectory. The driver can perform work orders in the PBX regardless of whether there is an object in eDirectory that should receive updates to phone information. But if you want to use the driver to update phone information in eDirectory for entities other than a user, one option would be to create eDirectory objects for those rooms or other entities, so that they can be identified by an ObjectID. Then you could customize the driver to update them the same way it can update user objects.