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 Section 7.0, Workforce Tree Configuration.)
What ID will you use to identify the user for whom the work order is being performed?
This ID number is entered in the work order as the ObjectID attribute, and you can use a custom policy 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. 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
field, it can be only 5 digits long.Keep in mind that this ID must also be entered in the PBX for any extensions entered manually.
How will you specify the user’s location so that the policies can determine where in the PBX to configure the extensions port?
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.
How will you determine whether a user should receive a DID or a non-DID extension?
You need to determine what business rules to follow. For example, you could customize the policies to assign non-DID extensions to users who work in a call center, based on job title.
It is not necessary to have both a DID and a non-DID range. If you only need one range, use the DID range. You can use two ranges if desired.
How will you determine the correct phone type for a user?
The phone type must be automatically assigned by the policies, 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.
Do you want to set phone use restrictions on extensions for certain users?
You can 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 can use criteria such as job title or the user object’s placement in the tree.
What user events do you want to automate with the driver, and what do you want the automated response to be?
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.
Do you want the driver to manage all existing users, or just provision new users? If you want the driver to manage existing users, some manual setup is necessary.
The Avaya PBX driver can manage new users. It can also manage existing users.
What do you want to use as the display name for an extension?
Determine what information from a user object you want the policies to use when creating the display name.
How do you want to handle extensions that are not assigned to a particular user, such as conference rooms or lab extensions?
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 is to create eDirectory objects for those rooms or other entities, so that they can be identified by an ObjectID. Then you can customize the driver to update them the same way it can update user objects.
What should you consider when implementing the driver with a work order database?
Keep in mind that you could use more than one container for work orders, such as one for work orders created in eDirectory manually, and one for work orders that come from the work order database.