How do I add a new Holiday Calendar to BMC Remedy SLM?
How to add a Calendar to SLM in Remedy 7.x
In BMC Remedy SLM you need to create a new holiday calendar every year (assuming your organization closes for holidays…).
I got this question a day or two ago. It’s a good question because there are two steps. The first one is easy – you create the calendar.
The second one is the easy one to forget – you have to associate the calendar with your SLM Business Schedule. If you skil that step – your calendar doesn’t work!
Fortunately this is pretty easy.
1.) Log into Remedy User
2.) Open the Home Page and go to Application Administration:
3.) Go to the “Custom Configuration” tab – expand the Service Level Management item and the Configure Business Time item. Double click on Shared Entity/Segments:
4.) Select the Business Time Segment tab – the following screen appears
5.) Select the “Create” button
6.) Create the new FY Calendar using this example – this is for the US Federal fiscal year 2010:
7. ) The following fields must be entered for the calendar to work correctly:
- Description
- Enable (check the box)
- Availability – set to “Unavailable” since the center is closed on Holidays
- Status – leave as “Draft”
- Action – set to “Create as Described”
- Duration type – set to Recurring
- Start Date – Fiscal Year start date (10/1/20??)
- Start Time – 12:00:00 AM
- End Date – Fiscal Year end date (9/30/20??)
- End Time – 11:59:59 PM
- Recurrence Type – Specific Dates
- Specific Dates – the upcoming Postal Holidays, separated by a semi-colon and then a space.
8.) Save the Calendar. Return to the previous screen.
9.) On the Business Schedules form choose the Business Time Entity tab:
10.) Choose the “Relate Activity” button
11.) Press the “Search” button on the screen that appears.
12.) Select the new Holiday calendar you created.
13.) Choose the “Relate Selected Record” button
14.) Confirm the new calendar is related to the schedule back on the previous screen.
That’s it – you are done. Just make sure you do steps 9-13. Otherwise it won’t work!
Site Changes
My Wordpress installation had major issues so it was time to re-do it. I also decided to move everything from www.williamrentfrow.com/wordpress/ to just www.williamrentfrow.com
It took me a few evenings to iron it all out (not to mention 171 301-style re-directs) but now I think everything is working.
If you find something broken please contact me. I’d appreciate it.
Importing Data into CTM:People in Remedy ITSM (Incident Management)
CTM:People Overview
If you are implementing BMC Remedy ITSM (aka, “remedy helpdesk”, Remedy Incident Management, etc) – you’ll end up import Customer and staff records into the CTM:People form at some point. Assuming, of course, that you are not insane and intend to enter them manually.
The Remedy ITSM suite uses People data for all of the following:
- User login name
- User rights management
- Customer/Contact information
In most environments all of this data exists in other places or will be compiled before the system is fully implemented. Consequently it is necessary to formulate a strategy for each of these data sources so the data can be used efficiently.
Ideally data will not be imported into the system unless there is a plan in place to perform automated updates in the future. The only exception to this would be the creation of new users which may occur in a non-predictable fashion. These would be added by the system administrator. Even in that case templates should be added for most user roles to make sure user roles are consistent. But that’s a blog post for another day.
The following basic facts about the Remedy system are relevant:
- In the OOB application the “Customer” (caller) must exist in the CTM:People form prior to saving an Incident.
- The best (in terms of least customization) method to deal with Customer data is to pre-populate the data in the forms. Populating the data at the time of the call will require a great deal of customization and testing.
- If you have different data sources duplicate data may exist. It may be impossible that to prevent this from happening since unique identifiers might not exist across systems. You’ll have to decide if that makes sense to your organization.
Remedy People Fields
All people in the BMC Remedy ITSM Suite applications are shared in the CTM:People form.
The following fields are required in the CTM:People data form and you’ll have to map data into them.
| Field Label | Field Type | Mandatory | Possible Values |
| Client Sensitivity | Selection | Yes | Sensitive Standard |
| Client Type | Selection | Yes | Office-Based Employee Field-Based Employee Home-Based Employee Contractor Customer Prospect Vendor |
| Company | Character | Yes | Valid configured OC |
| First Name | Character | Yes | Free form text |
| Last Name | Character | Yes | Free form text |
| Phone Number Business | Character | Yes | Free form text |
| Profile Status | Selection | Yes | Proposed Enabled Offline Obsolete Archive Delete |
| Submitter | Character | Yes | Default to $USER$ |
| Support Staff | Selection | Yes | Yes No |
| VIP | Selection | Yes | Yes No |
And there is one more thing – make sure you populate the hidden “full name” field. It gets used for displays a lot but it’s not a mandatory field to save the entry.
Enjoy! Importing people is usually one of the least fun parts of an implementation – it has to be done right, every time. But once you get this done the rest is easy.
Some BMC Remedy ITSM 7 Terminology
This is from 7.1 so it’s a bit dated already – but it could still be useful.
assignee
The person assigned the responsibility of working on any of the following activities: change request, incident ticket, problem investigation, known error, solution database entry, and so on.
assignment
Automatically or manually assigning a group or individual the responsibility of resolving an issue or request. ITSM applications use the Assignment form for group automatic assignment and the Assignment Engine for individual automatic assignment.
broadcast message
An application feature that enables users to create messages that can be viewed by the ntire organization or by users in specific groups.
CAB
See change advisory board (CAB)
change advisory board (CAB)
A group that advises change management on the implementation of significant changes to the IT infrastructure. This group is often made up of representatives from various IT areas and business units.
CI
See configuration item (CI).
Company field
A field in ITSM that controls multi-tenancy. It shows only data for the companies for which you have permission. See also multi-tenancy.
configuration item (CI)
An infrastructure component or an item associated with the infrastructure that is (or will be) under the control of configuration management, for example, a Request for Change. A CI can be complex or simple, large or small. CIs can include entire systems or be a single module or minor component. CIs can also include records of people (users and customers) and locations.
configuration management
The process of maintaining detailed IT inventory records. It involves identifying and defining the CIs in a system, recording and reporting the status of all CIs and requests for change, and verifying the completeness and correctness of all CIs. See also configuration item (CI).
dashboard
Web-based, graphical user interface using flashboards where compliance and service target results can be viewed by service level managers, service delivery managers, other IT professionals, and customers or line of business owners. See also service level agreement (SLA), service target, and flashboard.
decision tree
A step-by-step guide set up by an administrator. It guides the user through a questionnaire and, based on the user’s answers, completes part of the form for a new incident.
form
A collection of fields that represents a record of information in the AR System. AR System administrators can define and change the fields and workflow associated with a form. An AR System application can include many forms.
impacted area
Companies, locations, or organizations affected by changes or updates to CIs.
incident
Any event that is not part of the standard operation of a service and that causes an interruption to or reduction in the quality of that service. See also incident management and problem investigation.
incident management
As a concept, a reactive process typically initiated in response to a customer’s call. The primary goal of the incident management process is to restore normal service operation as quickly as possible and with minimum disruption to the business.
incident manager
A person who monitors incident tickets and activities to help plan resources and to identify incident trends. The incident manager also handles assignments.
incident matching
A search process in Incident Management that can be used to search for other incidents, problem investigations, known errors, and solution database entries that share some of the same characteristics as the current incident, such as product categorization.
incident owner
The user who records the incident. This user might differ from the current incident assignee. See also assignee.
Information Technology Infrastructure Library (ITIL)
A set of guidelines for the management and provision of operational IT services.
known error
A problem that has been successfully diagnosed and for which a temporary work-around or permanent solution to the known error has been identified. See also problem and work-around.
multi-tenancy
A feature in ITSM that uses the Company field to limit access by individuals. The Company field can be used to represent a company, department, or other group. The Company field also can be used to control access in a hosted environment. By default, ITSM applications operate in multi-tenancy mode. See also single-tenancy.
navigation pane
An area on the left side of consoles that provides links to functionality and links to other programs.
notification
A message sent to a user by workflow. Notification can be in the form of an alert, email message, or other method using integrations.
operational catalog
A feature in which operational categories for service requests are defined.
process flow
Shows the progress of a request as it moves through the stages of its life cycle. It does this within a form, such as an incident request. A diagram shows the stages of the process, as indicated by best practices, rooted in ITIL processes. It indicates the current stage and state of the request. The
process flow diagram also serves as a wizard, guiding the user through the life cycle.
product categorization
A five-tier hierarchical representation of products as defined in the Product Catalog configuration form. This categorization is included in records to specify the range of products to which the record applies.
registered user
A user who has an entry in the People form with an AR System login ID.
reminder
A message similar to an AR System notification, except that you can define the content of a reminder and specify when to send it.
requester
A person in the organization who needs assistance from the IT support staff. A requester is usually an employee in the organization who needs to have a change implemented or an incident resolved.
single-tenancy
A feature that allows selection of a default company for company fields in ITSM. Single-tenancy mode is required to give unknown users access to the ITSM Requester console. See also multi-tenancy.
submitter
A person who reports a problem, makes a request, or enters information into a database. See also change request.
task
A unit of work that needs to be completed as a step in implementing an incident or problem investigation. In the Change Management application, you can also group a number of activities for requests with a number of actions that need to be completed before the request can be resolved. Your administrator creates task templates and task group templates that you can reuse for the same types of requests. Tasks can be manual or automatic.
task management system (TMS)
A sub-system that is used to create task templates and task group templates. Besides the ability to set up predecessor-successor relationships, TMS supports branching and multiple task paths as well as the data exchange between activities.
template
1. A set of predefined criteria or settings that can be used by many agreements or service
targets. See also service level agreement (SLA).
2. A form set up by an administrator that a user can select to complete an incident ticket or a change request with information consistent with the user’s support group and the type of incident or change request.
BMC Remedy ITSM 7.x Tenancy Overview
A while back I did a write up on Tenancy in the BMC Remedy ITSM suite. So I thought I’d post it.
Single-tenancy and Multi-tenancy
Multi-tenancy is simply the new feature in BMC Remedy Service Desk that allows the system to be configured to allow for multiple “tenants”. A tenant is a self-sufficient Operating Company and/or business unit that has no need to interact with the other “tenants” on the system.
Configuring multiple “tenants” on one Remedy system is considered to be a “Multi-tenancy” implementation. Single tenancy is defining only on main Operating Company within Remedy Service Desk.
Users of the system are configured to see data from one or more of the defined Operating Companies. Typically the majority of the users only see data from the one Operating Company they work under. Some administrative users can see data from multiple or all Operating Companies.
The specific applications affected by single/multi-tenancy are:
- BMC Remedy Change Managment 7.x
- BMC Remedy Asset Management 7.x
- BMC Remedy Incident Management 7.x
- BMC Remedy Problem Managment 7.x
- BMC Remedy Service Level Managment 7.x