User Templates Model
A user template can be leveraged when creating a new user. If we have a common set of settings for a group of users maybe within the department, we could predefine those settings that are applicable to everyone in that department in the user template. And then when we add a new user we could apply that template and they inherit all those settings – could be a huge time saver for us. For example, this template might give everyone the same language, the same time zone, but something to keep in mind, if we go in and change that template after we've already added let's say a couple of dozen users that doesn't go back and update those existing users the template only gets referenced when we're creating a new user. So new users would inherit the new setting but the old users would not be updated. We could use something like the Bulk Administration Tool to make a mass update like that if we needed.
We've got a couple of pre-existing user templates. There's one for administrators and one for users. For example, an administrator could build a set of user templates for managers, employees, trainees. Maybe we want managers to have mailboxes with more space for voicemail messages. Maybe employees have been pre-configured with various message actions. Maybe trainees are limited to just listening to voicemail messages. We could also have templates based on a location within the company, a language that's spoken at that company location, the time zone of that company location. And when we do create a new user, and we select that user template we want to apply, the entries in the template are copied over to this new user.
General Settings vs. User Settings
Parameters impacting our users can be set in several different places. At a global level we could set enterprise or service parameters, and these parameters affect all of our user entries immediately. And if we want to think of this hierarchically, the next level down from those enterprise or service parameters is general settings. If we modify a general setting, this change affects all of our entries immediately. User templates though could override a general setting. For a new user, well like we said an update to a template is not going to impact any existing users, it's only going to be for new users. But we could go down to the user level in this hierarchy, and we could change a configuration parameter there.
Something changed directly at the user level, that's going to override the general setting. For example we might go into the manager's user account and say for their mailbox we want to have a larger mailbox quota.
User Template Basics
Here we see some of the more important user template settings.
For example, there is the name, the phone and the location settings. The name is an alias. It's the name of the user template. For example, "manager" might be the alias or the name associated with a manager's user template.
Next a dial plan is set in the phone area. This is going to dictate the partition to which a user belongs – the search space that they're allowed to search when they're trying to search for another user in the corporate directory. This is also where the class of service is configured. The class of service determines what features that a user has access to. For example, are they going to be able to receive voicemail messages in their IMAP e-mail inbox. Are they going to be able to use Cisco Unified Personal Communicator. Also into the phone category, that's where we would set a schedule for when a user's mailbox can answer or not.
The location setting determines the language associated with that user mailbox.
Default Class of Service
When we mention the term "class of service" in the context of a user template, we're not talking about the class of service that we see in Cisco Unified Communications Manager, and we're not talking about class of service as it relates to quality of service. Rather class of service in this context is talking about the features that an end user is going to have access to. There are two default CoS profiles that we have in Cisco Unity Connection. There is the system and the voicemail user CoS profiles.
The voicemail user CoS profile supports setting things such as timers. We've got default timers, for example there are 30 seconds that can be used to record a user's name, 90 seconds for the greeting, 300 seconds for the total message length – those are the defaults. The CoS also determines whether or not a user is listed in the directory. Or are they going to be searchable by other users? And the CoS determines what features that can be licensed are enabled or disabled. Can we access voicemail from an IMAP client? Can we use Cisco Unified Personal Communicator? Those may be enabled or disabled based on available licensing. CoS can also allow the enabling of alternate extensions, and set the number of private distribution lists that a user can create, and to allow or disallow an outgoing call transfer.
Password Settings and Roles
Earlier we talked about authentication rules, which would dictate for example what the minimum number of characters would be or the minimum number of numbers in a PIN, and whether or not a trivial password would be allowed. Well, let's think about that a bit more.
For security reasons Cisco recommends as a best practice that we do not allow the use of trivial passwords and that we do not enable the "does not expire" option. In other words we want to force the users to periodically change their PIN. And when you call into the system and it asks for your password, realize it's asking for your PIN, your Personal Identification Number. There is another password that can be set for the user, it's the web application password that's what's used by a user to access the Cisco Unity Connection user option pages. But in this context when we're talking about a password, we're talking about the personal identification number, and we can associate a certain authentication rule with a user to say what the restrictions are going to be. As an administrator we could go in and lock that user account, we could say the user account does not expire, we could change the password in accordance with the authentication rules and we could assign a role to this user. By default we don't have an administrator role assigned to a user but if we did, if we assigned a user to the administrator group, they would then have rights that would allow them to create new users.
Transfer Rules and Greetings
Let's now consider transfer rules and greetings. There are three predefined transfer rules:
The standard rule cannot be modified. It's enabled without an end date. The alternate rule, though, it could take precedence and replace the standard rule. It does have an end date. For example, beginning on Christmas and going through New Year's, we might want to have an alternate transfer rule that would be used instead of the standard transfer rule. We could also have a closed rule, which would be active on the weekends and after business hours. A standard greeting for a user might say something like "John Doe is not available". The name John Doe can be generated automatically from the display name by Cisco Unity Connection, and then we can have an alternate greeting used to personalize the voicemail box, and there could be a closed greeting that plays on the weekends. Be aware that a standard greeting is enabled by default and we have other parameters that we can define that dictates what the caller hears before the greeting, during the greeting and after the greeting. Or maybe we give the caller an option to select the language.
After a caller calls into Cisco Unity Connection and they hear the greeting, they could be offered a variety of options as to how to process this call. A common option is to take a message. Another option though is to transfer the call. We could use a call handler to transfer to another number. We could use an interview call handler to invoke an interview with that caller. We could have things set up such that an administrator could dial in externally and during an inclement weather condition this administrator might record a greeting such as "we're closed today because of inclement weather". The caller could be transferred to an external number maybe the mobile number of the user that was originally called, and we could have things set up such that directory numbers used by a team that have a shared mailbox – those directory numbers could forward the caller to another user mailbox, maybe if a certain phone number doesn't answer the call.
Message Actions and Caller Input
As we've seen below, messages can be handled in a variety of ways by a caller, and the caller can be given a TUI – a telephone user interface – to say how they want the message to be handled.
If a caller leaves a message they could be allowed to edit that message or maybe re-record the message. They could mark the message with a certain urgency, maybe a normal or an urgent importance. They could be asked to choose a message priority. And this could impact when the called party is going to get the message because maybe the called party only chooses to be notified for urgent messages. The caller could select actions such as accept, reject or relay the message, and if they choose to relay the message, a relay address needs to be specified, and perhaps the caller can enter input during the announcement. They could dial zero to get to the operator for example, they could press the * key to sign in. We could customize other digits to do other things. Maybe we customize the digit eight pressed during the announcement to transfer the caller to the helpdesk.
We were mentioning that the telephony user interface, or the TUI, would allow a caller to select how they want a message to be handled. Well interestingly we can modify the TUI experience not just for the caller but also for the Unity Connection user that has the mailbox. First, in the phone menu we could change parameters such as the conversation volume. We could change it from low to medium to high. We could set the conversation speed from slow to normal to fastest. The default by the way is a medium volume and a normal speed. We could set the time format to 12 hour or 24 hour. The default is 12 hour. We could set timers for entering digits. How long do we wait for the next digit when we're entering a name. The default is 3 seconds. And after the call, the call action, like we discussed, could be selected.
But when the Unity Connection user is playing back their messages, that experience could be modified by parameters such as the volume and the speed of the playback, whether or not we want to announce counters for how many new messages they have. We could say in what order messages are going to be played back. Are we going to playback messages in the order that they were received or, if we have a message flagged as urgent, should that play first? And we could also select what information that this user is going to hear about the message. They could get information about the sender's extension, the message number, the time that the message was sent, and if the user says that they want to delete a newer saved message, we could prompt them to confirm that they really want to delete it so they do not inadvertently delete a message that they really did want.