In a large organization, a User may be placed in one Group, and highly customized with services, settings, greetings, devices, and memberships in Group services. But later the User needs to be moved to a different Group. Example 1: The User's original Group may have grown impractically large, so that provisioning and management tools are inefficient. Example 2: Another reason to move a user between groups may be Call Pickup Groups (CPG): if a user needs to be in the same CPG with another, they must be in the same Group.
In these cases, deleting the User from one Group, then adding them back to the other, is a disruptive operation. A human operator needs to collect details on every setting, and on the User's device. To minimize the effect on Users moved, even their passwords must be migrated to their new group.
This feature, User Migration, provides a function that allows BroadWorks' Users to be moved from one Group to another Group with no loss of information, settings, passwords, greetings, or attached files.
User Migration can be accessed via the Migration button within the Actions tab on User page. Note that you can return to any previously completed step by clicking the check mark next to the step name.
- Once on the User Migration page, click the Start button to begin the process. Once clicked, the encumbrance check will begin.
- If no encumbrances are found, the next step will appear. Otherwise you may not proceed until the encumbrances are resolved.
- In this step, you must choose the Group you wish to migrate the User to. Once chosen, click the Check Requirements button to proceed.
- If no requirements are found, the next step will appear. Otherwise you may not proceed until the requirements are resolved.
- If all checks pass, the migrate step becomes available. Click Migrate User to begin the migration process.
- After the button has been pressed, you will be re-directed to the task page where you can monitor the status of the migration.
User Migration performs a sequence of information retrieval prior to migration to ensure that the User meets the set of requirements that will allow the User to successfully migrate to the Destination Group. There are two types of restrictions that would prevent a valid migration - Requirements and Encumbrances. If either one of the restrictions contains errors then the migration will not be allowed to procede.
- Check Migration Validity
- Migrate Access Device
- Remove User
- Migrate Phone Number
- Create New User
- Set BLF entries on monitoring Users
- Set Non-Service User settings
- Add and Assign Services and Service Packs
- Add Custom Announcements
- Add Service specific settings
- Add Credentials
- Rebuild Access Device Configuration
Following the information retrieval process the full details of the User are backed up for recovery purposes. The settings information retrieved is backed up as JSON. Announcement files and device configuration files are backed up in their original format. These files collectively can be used for recovery purposes.
Requirements are restrictions that are determined by inspecting the desired Destination Group to determine if the User can be moved into the Destination Group successfully.
- Intra-Enterprise Inter-Group
- The source and destination group must exist within the same Enterprise.
- The Domain (e.g., "xyz.com") that is applied to the User (at the Profile), and to the User's Identity/Device Profile Line/Port, must exist in the target group.
- Service and Service Pack Authorization
- Services and Service Packs that the User is currently assigned must be available within the Destination Group.
- Group Schedules
- The schedules contained within the User’s Source Group must also be contained within the User’s Destination Group.
- Group User Limit
- The Destination Group must have sufficient user availability to perform the move.
- Group Extension Length
- The Destination Group must have a valid extension length for the User.
- Group Extension Availability
- The Destination Group must have a the current User extension available.
- Department Availability
- If a User is assigned to a Department, the Destination Group must have that Department available as well.
- User Voice Messaging
- If a User has the Voice Messaging User service assigned, either the Destination Group has to have Voice Messaging Group assigned or a System Voice Portal must exist otherwise the migration is not valid.
- Feature Access Code
- If a User's source Group has a Service assigned that adds extra Feature Access Codes, then the Destination Group must also have the service assigned to prevent loss of data. An example of this is Hunt Group. If a Group has the Hunt Group service assigned, the following Feature Access Codes are added to the User: Hunt Group Busy Activation, Hunt Group Busy Deactivation, Hunt Group Busy Interrogation.
Encumbrances are restrictions that are contained within the User’s settings and the User’s Access Device’s settings. These restrictions do not require a Destination Group to be determined and can be checked in advance for potential migration targets.
- Shared Call Appearance
- If the User has a Shared Call Appearance assignment on a Identity/Device Profile, and the Identity/Device Profile is a Group-Level resource, and if the Identity/Device Profile has any other User or Shared Call Appearance assigned to it, the User is not moved.
- Call Pickup Group
- If the User is a member of a Call Pickup Group, the User is not moved.
- Attendant Console
- If the User is monitoring any users, then the User will not be moved.
- Meet-Me Conferencing Bridge
- If the User has a Meet-Me Conferencing Bridge assigned, the User will not be moved.
- Single-User Device
- If the User is assigned to an Identity/Device Profile, and this is a group-level resource, then the Identity/Device Profile must have only this one user assigned to it. That is, the Group-level Identity/Device Profile cannot have multiple users assigned to it.
- Hunt Group
- If the User is a member of a Hunt Group they cannot be moved.