.. _reassign-services-overview:
Reassign user services
-----------------------
.. _19.1.1|VOSS-512:
.. _19.2.1|VOSS-512:
.. tip::
:ref:`use-action-search-to-navigate-automate`
Overview
.........
Reassign user services simplifies and automates the transfer of existing
user services from a source user to a target user.
.. rubric:: Reassign services high level workflow
.. uml::
@startuml
'Reassign Services High Level Workflow
!include style.iuml
start
:[[../src/user/concepts-reassign-services-overview.html#reassign-services-profile Reassign Services Profile ]];
note right
Set up your profiles before proceeding.
end note
if (Do you want to reassign or update user services?) then (reassign)
:[[../src/user/concepts-reassign-services-overview.html#reassign-a-user-s-service Reassign User Services ]];
else (update)
:[[../src/user/concepts-reassign-services-overview.html#update-a-user-s-details Update User Services ]];
endif
stop
@enduml
This utility is for example useful when an employee leaves an organization and a new employee
starts the same role. Instead of removing the old user and configuring a new user with
the same settings and standards, the services and settings
can be moved from the old user to the new user.
These services can include:
* Fixed phones
* Device Profile(s)
* Remote Destination Profile(s).
Remote destination needs to be set up for the target user separately
* Voicemail user with related services including
alternate extension and message handle (action)
.. note::
Webex (Meetings and App) and CCX services are not currently supported by this feature.
Custom settings can be applied to these services during the reassignment.
A **Reassign Services Profile** setting is available to choose the configuration
templates that will be used to update services during reassignment. These
allow you to customize most settings on any of the above devices, including
Line Alerting Name, Line Label, DisplayASCII values, and so on.
Example templates are provided that contain macro variables for
fields that are likely to differ between users. The field values
then resolve with input from existing target user details.
In this way the templates are not limited by for example a Site and Phone Model.
When reassigning services from existing source users to existing target users,
the latter are moved to the *same site* as the source user, if these differ.
It is also possible to create a new target user as part of the "reassign services" process
instead of selecting an existing user
without services. This user will be created at the same site
as the source user.
Other features included are:
* Change User Details (modified Reassign Services) that updates the
services of an existing user using custom templates referenced
in a Reassign Services Profile.
.. rubric:: Related topics
* :ref:`reassign-services`
* :ref:`reassign-services-update`
* :ref:`reassign-services-profile`
* :ref:`ini-reserve-for`
.. _reassign-services:
Reassign a user's service
..........................
The Reassign Services functionality requires that you select a customer hierarchy (if you
are not already there) since it supports target users that are on a different site to the source user.
.. uml::
@startuml
!include style.iuml
start
:Choose Reassign Services Profile;
:Choose Source User;
:Add or choose Target User;
note right
You can create a new target user at the
same hierarchy as the source user.
end note
:Add Target User credentials;
stop
@enduml
.. tabularcolumns:: |p{4.5cm}|p{10.5cm}|
+------------------------------+-------------------------------------------------------------+
| Field Name | Comment |
+==============================+=============================================================+
| | This field will pre-populate with the first |
| **Reassign Service Profile** | profile. You can select a different profile |
| | if required. If no profile option is |
| | available, then a reassign service profile |
| | needs to be added in the system. |
+------------------------------+-------------------------------------------------------------+
| | Choose the user to be reassigned. This |
| | provides a list of usernames of users in |
| | the system. It will list local or CUCM-LDAP |
| | Synced users only (not Automate-LDAP synced) |
| | Once a user is selected, the |
| **Source User** | **Source User Services** tab is updated to show |
| | services currently assigned and that will be |
| | reassigned to the target user. This is a good |
| | way to validate that all the services are |
| | shown or that there are not services that you |
| | do not want reassigned. |
+------------------------------+-------------------------------------------------------------+
| | Once a user is selected the **Source User Hierarchy** |
| **Source User Hierarchy** | will be populated - this is a read-only |
| | informational field. |
+------------------------------+-------------------------------------------------------------+
| | Select this option if you need to add a new |
| **Add A New Target User** | local user to the system as the target user. |
| | Once selected, the form updates to reflect |
| | this choice. |
+------------------------------+-------------------------------------------------------------+
| | To reassign to an existing user: select the |
| | username from the dropdown. This will show |
| | local or CUCM-LDAP synced users at the |
| | customer level or lower. Once a user is |
| | selected, the **Target User Services** tab is |
| | updated to reflect any services currently |
| | assigned to the user. If the user has any |
| **Target User** | entries on this tab then the transaction will |
| | be blocked. So this provides an option to |
| | check before submitting. |
| | |
| | To create a new target user: enter the |
| | username for the new user to be created. The |
| | user will be added to the same hierarchy as |
| | the source user. |
+------------------------------+-------------------------------------------------------------+
| | Shown only if add new target user is not |
| | selected - read-only informational field. |
| | |
| **Target User Hierarchy** | Shows the hierarchy of the selected target |
| | user. Can be different to the source user and |
| | the feature will move the target user to the |
| | same hierarchy as the selected source user. |
+------------------------------+-------------------------------------------------------------+
| | First Name of the Target user. Will be read |
| **First Name** | only if the target user is a LDAP synced user. |
| | |
+------------------------------+-------------------------------------------------------------+
| | Last Name of the Target user. Will be read |
| **Last Name** | only if the target user is a LDAP synced user. |
| | |
+------------------------------+-------------------------------------------------------------+
| | Email Address of the Target user. Will be read |
| **Email Address** | only if the target user is a LDAP synced user. |
| | |
+------------------------------+-------------------------------------------------------------+
| | Visible if the target user is not a LDAP |
| **Password** | synced user. Enter the password for the |
| | target user. |
+------------------------------+-------------------------------------------------------------+
| **Pin** | Enter the PIN for the target user (used for |
| | device profile and voicemail). |
+------------------------------+-------------------------------------------------------------+
Notes:
* The feature requires that source user services should all be at the
same site hierarchy.
* Target user and hierarchy:
* New target user - will be added to the hierarchy of the source
user.
* Existing target user - If the target user is in a different hierarchy
to the source user, the target user will be moved to the same
hierarchy as the source user as part of the reassign of services.
.. note::
It is not possible to reassign services to a user who
is on a different CUCM Cluster than the source user.
The target user drop-down will currently not show users
on a different cluster.
* The **Source User Services** tab will populate once a source user has
been selected. This shows the services currently assigned to that user
and the services that will be reassigned. This is a good way to
validate the services that will be reassigned and to check if there are
any services missing or that should not be reassigned. This can then
be corrected as needed before reassigning the services.
* The **Target User Services** tabs will populate once a target user is
populated. This is a good way to validate that the target user does
not currently have any services assigned, as this will cause the
transaction to fail with an error message indicating the target user
has services. This can be resolved by choosing a different target user
or by removing the services currently configured for the target user.
* Based on the setting in the reassign profile, the source user will
either be left in the system (without any services) or removed from
the system entirely.
Most of the services are updated to be associated to the target user and
have settings updated according to the Configuration Templates (CFTs) in the reassign profiles.
There are some considerations:
* Single Number Reach (SNR) - Any existing remote destinations
configured for the source user are deleted. The Remote Destination Profile (RDP) is then
associated to the target user and updated per the CFT in the reassign
services profile.
* Voicemail - the existing voicemail service for the source user is
deleted to ensure a clean voicemail service. The voicemail service is
then rebuilt for the target user based on the CFT in the reassign
service profile. This means that any personalized settings, messages,
greetings, and so on are cleared.
* Shared lines - Shared lines associated to the source user will only be
updated if the shared line is the source user's primary extension.
The feature includes the optional ability to update shared line
appearances of the source user's lines on other users' phones to reflect
the destination user's details. For example:
* Bob.Smith has a phone with the following:
* Line1: 55210 - Label: Bob Smith 55210
* Mary Smith has a phone with the following:
* Line 1: 55220 - Label: Mary Smith 55220
* Line 2: 55210 (shared line appear of Bob) - Label: Bob Smith 55210
In this case, when Bob's service is reassigned to a new user, Mary's Line
2 appearance will need to be updated to reflect the new user (e.g display
name, label, etc.). This is supported for line appearances on Phones,
Device Profiles, and Remote Destination Profiles. See the reassign
services profiles section for more details on the controls.
.. rubric:: Related topics
*
.. raw:: latex
Shared Lines in the Core Feature Guide.
.. raw:: html
Shared Lines
.. _reassign-services-update:
Update a user's service
.........................
The **Update User Services** tab/panel displays a simplified form of Reassign Services where only
one source user is selected, and that user's services are updated using custom
configuration templates referenced in a *reassign services* profile. The
input fields allow for an easy update of basic details such as
First Name, Last Name, Email, Password and PIN. User services
that use any of the updated user details will automatically get updated.
The **Reassign Services Profile** drop-down list is
available to select a profile to be used to also update the user's
services details.
Similar to Reassign Services, selecting a Username auto-populates the Hierarchy
of the selected user and the **Current User Services** tab/panel displays the services that
will be updated.
.. rubric:: Reassign User Services (Update user services workflow)
.. uml::
@startuml
'Reassign User Services Update User Services Flowchart
!include style.iuml
start
:Choose Reassign Services Profile;
:Choose User;
:Modify user credentials;
note right
User services that use any of the updated
user details will automatically get updated.
end note
stop
@enduml
.. _reassign-services-profile:
Reassign services profile
.............................
.. tip::
:ref:`use-action-search-to-navigate-automate`
The **Reassign Services Profile** page allows for a set of configuration
settings and additional settings to apply when using *reassign services*
functionality.
.. rubric:: Reassign services profile configuration workflow
The flowchart describes the configuration settings to apply. If no configuration template is defined for a
service, it is still moved to the new user. However, existing settings are left in place.
.. uml::
@startuml
'Reassign Services Profile Workflow
!include style.iuml
start
if (Do you have the required CFTs?) then (Yes)
else (No)
:Create required CFTs;
note right
You can clone CFTs from the ""RS Example Profile""
to your hierarchy and modify them.
end note
endif
:Choose required CFTs;
:Select additional services options;
:Enter Profile name, description and save;
@enduml
Configuration templates and reassign services profile
''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Configuration templates (CFTs) selected in the profile determine how many of the detailed
settings of the
various services are updated as part of the reassign. This will allow you to re-align settings to your
baseline service deployment
logic and update any settings that incorporate the user's name - for example
descriptions, alerting/display names, labels, and so on.
If no CFT is defined
for a service, it is still moved to the new user. However, existing settings
will be left in place. There are a few cases where the feature will make
updates to specific service settings regardless of the CFT (i.e. when
these settings are required to associate the user and service - owner of a
phone, associated devices on the UCM user, etc). If the source user does
not have a given service (e.g voicemail) then any CFT in the profile is
ignored as the feature does not add new services that did not exist on the
source user.
Automate ships with a collection of sample CFTs (prefixed ``RS``), which
provide examples of common settings and logic.
This profile and templates for configuration settings can be maintained
per hierarchy as needed. The reassign services feature is similar to Quick Add User, allowing
re-use of macros/logic from your Quick Add Group CFTs in the reassign services
profiles. In many cases you could even use the same CFT to ease
maintaining multiple sets of CFTs that define the baseline user and
service configuration.
.. note::
At least one reassign services profile must be added to use the reassign user services functionality.
Reassign services profile settings
''''''''''''''''''''''''''''''''''''
Go to **Reassign Services Profile**, then choose an existing profile to view its settings, or to add a new profile.
.. tabularcolumns:: |p{4.5cm}|p{10.5cm}|
+------------------------------------------------+--------------------------------------------+
| Field | Description |
+================================================+============================================+
| | Name for the Profile - recommended to make |
| **Profile Name** | it meaningful to the user's that will be |
| | using the feature if you need more than |
| | one profile. |
+------------------------------------------------+--------------------------------------------+
| **Profile Description** | Description for the profile |
+------------------------------------------------+--------------------------------------------+
| | If selected the feature will fully remove |
| | the source user after moving all the |
| **Remove Source User** | services. If not selected then the base |
| | user and user will be left when the |
| | feature completes however no services will |
| | be enabled. |
+------------------------------------------------+--------------------------------------------+
| **User CFT** | This CFT defines Automate user settings to |
| | apply to the target user - e.g. role |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the UCM User settings to |
| **CUCM User CFT** | apply for the target user - e.g |
| | Department, Service Profile, etc. |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the UCM Line settings to |
| **Line CFT** | apply for the target user - e.g. |
| | Description, Alerting Name, Pickup Group, |
| | Call Forwarding, etc |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the Phone settings to |
| | apply to the devices being moved - e.g. |
| | Line Label, display name, device pool, |
| | CSS, etc. This same CFT applies to all |
| **Phone CFT** | phones (hardphones, soft-clients, etc) so |
| | typically relate to line appearance |
| | settings or other non-phone type specific |
| | settings. ownerID, mobility user (for |
| | soft clients) as set via the workflow |
| | irrespective of the CFT. |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the Device Profile |
| | (extension mobility) service for the user |
| **Device Profile CFT** | - e.g Line label, display name, etc. As |
| | with the Phone this is typically for line |
| | appearance settings on the device profile. |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the Remote Destination |
| | Profile (Single Number Reach - SNR) |
| **Remote Destination Profile CFT** | settings to apply to the service being |
| | moved - e.g line label, display name, |
| | CSSs, etc. Again typically for updating |
| | line appearance settings but can also edit |
| | other base RDP settings. |
+------------------------------------------------+--------------------------------------------+
| | This CFT defines the CUC User (Voicemail) |
| **CUC User CFT** | settings to apply when setting up |
| | voicemail for the user. |
+------------------------------------------------+--------------------------------------------+
| | This setting determines if the feature |
| | will add a voicemail alternate extension |
| | for the user if voicemail exists on the |
| **Add CUC User Alternate Extension** | source user. This can be used to add a |
| | standard alternate extension (e.g short |
| | extension version of the user's number) if |
| | needed as part of your standard |
| | deployment. |
+------------------------------------------------+--------------------------------------------+
.. tabularcolumns:: |p{4.5cm}|p{10.5cm}|
+-------------------------------------------------------------------------+--------------------------------------------+
| Field | Description |
+=========================================================================+============================================+
| | This setting is visible if the add |
| | alternate extension setting above is true. |
| **CUC Alternate Extension CFT** | This CFT determines the settings for the |
| | alternate extension that will be added. |
| | This is where you would define the |
| | alternate extension to be added as |
| | standard. |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting determines if the feature |
| **Update CUC User Message Handler (Action)** | will configure the message handler |
| | settings for voicemail (form of single |
| | inbox). |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting is visible if the message |
| | handler setting above is true. This CFT |
| **CUC Message Handler (Action) CFT** | determines the settings that will be |
| | configured for the message handler. So |
| | this will need to include the email |
| | address for example of the user as well as |
| | the message actions. |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting determines if the feature |
| | will update line appearances of the source |
| | user's lines on other user's devices. |
| | This can be used to update the display |
| | names or labels for instance on those |
| | remote devices to reflect the new user's |
| | details. |
| | |
| **Update shared lines (for unassociated Phones, Device profiles, RDP)** | These CFTs only apply to line appearance |
| | settings on those devices (not general |
| | phone settings) and only for the line |
| | appearances that are shared with the |
| | source user. Other line appearances on |
| | the devices will not be updated. For |
| | example, the other user's phone had 3 |
| | lines, only 1 of which was shared with the |
| | source user. Only that 1 line appearance |
| | will be updated and the other 2 will be |
| | left untouched. |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting is visible if the Update |
| **Shared Line (unassociated Phone) CFT** | Shared Line setting is true. This CFT |
| | determines the settings on the other |
| | users' Phones that have the line |
| | appearance. |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting is visible if the Update |
| **Shared Line (unassociated Profile) CFT** | Shared Line setting is true. This CFT |
| | determines the settings on the other |
| | users' Device Profiles that have the line |
| | appearance. |
+-------------------------------------------------------------------------+--------------------------------------------+
| | This setting is visible if the Update |
| **Shared Line (unassociated RDP) CFT** | Shared Line setting is true. This CFT |
| | determines the settings on the other |
| | users' RDP that have the line appearance. |
+-------------------------------------------------------------------------+--------------------------------------------+
Typically, configuration templates similar to your current Quick Add User templates can be used.
Example configuration templates are also available for each drop-down, with naming convention
``RS Example CFT``. The templates shown on the **Configuration Templates** menu
can be cloned, renamed and modified per hierarchy as required.
Configuration examples:
* Template Name: ``RS Example CUCMPhone CFT``
Field: **Line** > **Display Ascii**
Value: ::
((input.firstName == fn.null ))
<{{input.lastName}}>
<{{input.firstName}} {{input.lastName}}>
* Template Name: ``RS Example CUCMLine CFT``
Field: **ASCII Alerting Name**
Value: ::
{{fn.sub_string input.lastName, 0, 30}}
Additional optional settings available:
* **Add CUC User Alternate Extension**:
If checked, a drop-down is enabled to select a template that updates the alternate extension.
Example template: ``RS Example CUCAlternateExtension CFT``
Field: **DisplayName**
Value: ::
{{ input.firstName }} {{ input.lastName }} Alt
* **Update CUC User Message Handler (Action)**:
If checked, a drop-down is enabled to select a template that updates the email address for single inbox.
Example template: ``RS Example CUCMessageHandler CFT``
Field: **RelayAddres**
Value: if no input email address is available, a dummy address is added
* **Update shared lines (for unassociated Phones, Device profiles, RDP)**:
If checked, a drop-down is enabled to select a template so that for any shared line instances from the source user,
line label details can optionally be updated with those of the target user. The **Line CFT** template updates do
not apply to shared lines.