BMC Remedy Action Request System 7.6.04 Concepts Guide

BMC Remedy Action Request System 7.6.
04
Concepts Guide
January 2011
www.bmc.com
Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada

Address
BMC SOFTWARE INC

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or

800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada

Telephone
(01) 713 918 8800
If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.
Copyright 19912011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
IBM, AIX, DB2, and Informix are trademarks or registered trademarks of International Business Machines Corporation in the United
States, other countries, or both.
Linux is the registered trademark of Linus Torvalds.
IT Infrastructure Library is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc.,
under license from and with the permission of OGC.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
UNIX is the registered trademark of The Open Group in the US and other countries.
The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or
licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product
and to the proprietary and restricted rights notices included in the product documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF
THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to
restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and
DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX
77042-2827, USA. Any contract notices should be sent to this address.
Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see Before Contacting BMC Software.
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support. From this website, you can:
Read overviews about support services and programs that BMC Software offers.
Find the most current information about BMC Software products.
Search a database for problems similar to yours and possible solutions.
Order or download product documentation.
Report a problem or ask a question.
Subscribe to receive email notices when new product versions are released.
Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.
Support by telephone or email

In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:yourSupportContractID, such as SupID:12345.) Outside the United States and Canada, contact your
local support center for assistance.
Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:
Product information
Product name
Product version (release number)
License number and password (trial or permanent)
Operating system and environment information
Machine type
Operating system type, version, and service pack
System hardware configuration
Serial numbers
Related software (database, application, and communication) including type, version, and service pack or
maintenance level
Sequence of events leading to the problem
Commands and options that you used
Messages received (and the time and date that you received them)
Product error messages

Messages from the operating system, such as file system full
Messages from related software
License key and password information

If you have a question about your license key or password, contact Customer Support through one of the following
methods:
E-mail customer_support@bmc.com. (In the Subject line, enter SupID:yourSupportContractID, such

as SupID:12345.)
In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.
Submit a new issue at http://www.bmc.com/support.
Contents
Preface
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 1
About BMC Remedy Action Request System
11
What is AR System?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a service desk solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System mid tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heterogeneous environment provides flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . .
Distributed environments provide scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preserving customizations with overlays and custom objects . . . . . . . . . . . . . . . .
How application components work together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administrator responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Developer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmer responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
12
13
14
16
18
18
19
20
20
21
23
24
25
26
26
Chapter 2
27
Forms and applications
About AR System forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Types of forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Form views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reports based on form data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characteristics common to all fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Core fields in a regular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Field menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forms in applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Localized applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
29
30
31
32
33
33
34
35
36
Chapter 3
37
Workflow
Workflow in general and in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Contents
Types of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Workflow based on events versus time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Workflow running on clients versus servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Collections of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Workflow actions and execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Workflow actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Workflow execution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Workflow qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Keywords in qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 4
Access control
49
About access control in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

User and group access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Types of access control groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Additive permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Membership in multiple groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Role-based access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Multitiered access control model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Access control levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
How licensing affects access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
License types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 5
Extending AR System
59
AR System foundation products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

BMC Atrium products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
AR Systembased solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Other BMC products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Integration with third-party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Chapter 6
An example BMC Remedy AR System application
63
About the wild animal park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Goals of the animal tracking application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Analyzing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Analyzing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Defining business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Mapping business rules to workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Considering integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Putting the example application to work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Example applicationA tiger is acquired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Example applicationThe tiger is injured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Example applicationThe tiger is traded to another zoo . . . . . . . . . . . . . . . . . . . . 71
Appendix A
Index
Concepts Guide
Glossary
75
95
Preface
This guide discusses core concepts of BMC Remedy Action Request System
(AR System). AR System is the foundation for a wide range of business solutions,
from service desk call tracking to inventory management to integrated systems
management.
Audience
This guide is primarily for new administrators who will use AR System to create
or modify applications. Other audiences, including business managers and
persons evaluating and prototyping applications based on AR System, might also
find this guide helpful. Procedures, performance, and other topics are documented
in the books listed in the following section.
AR System documents
The following table lists documentation available for AR System 7.6.04.
Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is
available on AR System product installation DVDs, on the Customer Support
website (http://www.bmc.com/support), or both.
You can access product help through each products Help menu or by clicking
Help links.
NOTE
The AR System product help has not been updated for version 7.6.04. The help
topics still apply to version 7.6.03. For the most recent content, refer to the PDF
documentation.
Title
Description
1
Audience
Concepts Guide
Overview of AR System architecture and features; includes Everyone

information about add-on products that extend AR System
functionality and a comprehensive glossary for the entire
AR System documentation set.
Installation Guide
Instructions for installing AR System.
Administrators
Preface
BMC Remedy Action Request System 7.6.04
Title
Description
Audience
Introduction to Application
Development with BMC
Remedy Developer Studio
Information about the development of AR System

applications, including an introduction to using
BMC Remedy Developer Studio.
Developers2
Form and Application Objects Information about AR System applications and their user
Guide
interface components, including forms, fields, views,
menus, and images.
Developers
Workflow Objects Guide
Information about the AR System workflow objects (active Developers

links, filters, and escalations) and how to use them to create
processes that enforce business rules.
Configuration Guide
Information about configuring AR System servers and

clients, localizing, importing and exporting data, and
archiving data.
Administrators
BMC Remedy Mid Tier Guide Information about configuring the mid tier, setting up
applications for the mid tier, and using applications in
browsers.
Administrators
Integration Guide
Administrators/
Instructions for integrating AR System with external
systems by using web services, plug-ins, and other products, Developers/
including LDAP, OLE, and ARDBC.
Programmers3
Optimizing and
Troubleshooting Guide
Information about monitoring and maintaining AR System Administrators/

and AR System applications to optimize performance and Developers/
solve problems.
Programmers
Database Reference
Database administration topics and rules related to how

AR System interacts with specific databases; includes an
overview of the data dictionary tables.
Administrators/
Developers/
Programmers
BMC Remedy Distributed

Server Option Guide
Information about implementing a distributed AR System

server environment with BMC Remedy Distributed Server
Option (DSO).
Administrators
BMC Remedy Flashboards

Guide
Instructions for creating, modifying, and administering

Administrators/
flashboards to display and monitor AR System information. Developers
C API Reference
Information about AR System data structures, C API

function calls, and OLE support.
Programmers
C API Quick Reference
Quick reference to C API function calls.
Programmers
Java API
Programmers
Information about Oracle Java classes, methods, and
variables that integrate with AR System. For the location of
the JAR file containing this online documentation, see the
information about the Java API in the Integration Guide.
Java Plug-in API
Information about Java classes, methods, and variables used Programmers

to write plug-ins for AR System. For the location of the JAR
file containing this online documentation, see the
information about plug-ins in the Integration Guide.
BMC Remedy Email Engine

Guide
Instructions for configuring and using BMC Remedy Email Administrators

Engine.
Error Messages Guide
Descriptions of AR System error messages.
Administrators/
Developers/
Programmers
Master Index
Combined index of all books.
Everyone
Concepts Guide
AR System documents
Title
Description
Audience
BMC Remedy Approval

Server Guide
Instructions for using BMC Remedy Approval Server to

automate approval and signature processes in your
organization.
Administrators
Release Notes
Information about new features, compatibility, and

international issues.
Everyone
Release Notes with Known

Issues
Information about new features, compatibility, international Everyone

issues, installation planning, and open issues.
BMC Remedy User Help
Instructions for using BMC Remedy User.
Everyone
BMC Remedy Developer

Studio Help
Instructions for using BMC Remedy Developer Studio to

develop AR System forms, workflow objects, and
applications.
Developers
BMC Remedy Data Import

Help
Instructions for using BMC Remedy Data Import.
Administrators
BMC Remedy Alert Help
Instructions for using BMC Remedy Alert.
Everyone
BMC Remedy Mid Tier

Configuration Tool Help
Instructions for configuring BMC Remedy Mid Tier.
Administrators
BMC Remedy Browser

Help
Instructions for using AR System forms in browsers.
Everyone
BMC Remedy Migrator 7.6.04 Outlines procedures for installing BMC Remedy Migrator,
BMC Remedy Migrator Guide setting options, and performing migration tasks.
Administrators /
Developers
BMC Remedy Migrator

online help
Administrators /
Developers
Procedures for setting BMC Remedy Migrator options and

performing migration tasks.
BMC Remedy Encryption

Provides an overview of the BMC Remedy Encryption
Administrators
Security 7.6.04 BMC Remedy Security products and explains how to install and configure
Encryption Security Guide
them.
1 The full title of each guide includes BMC Remedy Action Request System 7.6.04 (for
example, BMC Remedy Action Request System 7.6.04 Concepts Guide), except the
BMC Remedy Migrator Guide and BMC Remedy Encryption Security Guide.
2 Application developers who use BMC Remedy Developer Studio.
3 C and Java programmers who write plug-ins and clients for AR System.
Preface
10
Concepts Guide
Chapter
About BMC Remedy Action

Request System
This chapter introduces BMC Remedy Action Request System (AR System)
architecture and application components and explains how they fit together to
address your organizations needs.
The following topics are provided:
What is AR System? (page 12)

AR System architecture (page 14)
Application components (page 21)
Administrator responsibilities (page 25)
Developer responsibilities (page 26)
Programmer responsibilities (page 26)
Chapter 1 About BMC Remedy Action Request System
11
What is AR System?
Every company, whether it makes bicycles or provides worldwide
telecommunications services, has its own business needs and processes. BMC
Remedy Action Request System (AR System) enables you to automate many
business processes without learning a programming language or complex
development tools.
AR System is a professional development environment that
Leverages the best practices of the IT Infrastructure Library (ITIL)
Provides a foundation for Business Service Management (BSM) solutions
Using AR System, nonprogrammers can build powerful business workflow

applications and deploy them simultaneously in web, Windows, UNIX, and
Linux environments.
Applications built with AR System can automatically track anything that is
important to the processes in your enterprise. Companies use AR System
applications to track such diverse items as stock trades, benefits data, inventory
assets, spare parts, and order fulfillment. With sufficient planning, even workflowintensive procedures can be automatically maintained in an orderly manner.
Example of a service desk solution

One of the most common uses of AR System is to automate internal service desks.
The following example illustrates a service desk solution in which AR System
solves an employees problem.
Ramonas printer would not work, so she logged in to her companys AR System
service desk portal and entered information about the problem. The system
automatically offered several knowledge base articles that might apply to her
problem, but none resolved the issue for her.
Ramona then opened a service desk request through the portal to get further
assistance from the IT department. When she entered her phone number into the
blank request form on her screen, details of her configuration and location
automatically appeared in the form. Ramona filled in the remaining details about
her problem and submitted the request. She immediately received a message
informing her that the case had been assigned to Becky.
Becky was automatically paged and used her computer to review the problem.
Using her knowledge of similar problems, she fixed the printer and marked the
case closed. Ramona was then notified that the problem was fixed.
If Ramonas problem had been an emergency that was not handled within an hour,
the system would have automatically paged the appropriate support personnel
and sent an email message to Ramona, informing her of the request status.
In this example, AR System automated the offer of knowledge base articles, the
entry of information in the form, the assignment notification, the paging system,
the closure notification, and the emergency response.
12
Concepts Guide
What is AR System?
A service desk application and other ready-to-use AR System applications are

available from BMC and its partners (see Chapter 5, Extending AR System). You
can also create your own custom solutions.
AR System adaptability
AR System strikes a balance between hard-coded applications, which are typically
inflexible, and development toolkits, which often require extensive technical
knowledge and time to use. Instead, AR System provides a platform from which
even nonprogrammers can modify ready-to-use BMC applications or create
custom applications to fit their unique enterprise.
Figure 1-1: AR System adaptability
Perhaps the best way to understand the adaptability of AR System is through an

example. Paul owns a small video store and installs AR System to help track
inventory. Initially, he builds a simple application that has one form. The form
collects the video title, rating, format, number of copies, and rental fee. When his
business grows and he needs to track employees, he adds a form that collects the
employee number, salary, start date, training, and time card.
Next, Paul links his application to a credit/debit verification system by using the
AR System open application programming interface (API). Later, he adds an order
tracking and purchasing application to automatically order items through web
services. He then creates a website to enable customers to order movies and pay
rental fees online, and to store their rental history in a knowledge base. He further
automates the system to provide proactive movie suggestions based on this rental
history.
13
Thanks to the rapid growth of his business and the flexible, adaptable architecture
of AR System, Paul opens new stores in cities across the country. He links all the
stores into one system and uses real-time graphic flashboards to track his entire
operation. Paul can track incidents, inventory, employee information, order
processing, and customer satisfaction from his office, and he can easily extend or
modify his system whenever changes occur in his organization.
AR System architecture
AR System is based on a multitiered client/server architecture that includes the
client tier, the mid tier, the server tier, and the data tier.
14
Client tierContains AR System clients. Most clients present information to

application users and receive input from them, but the tools for migration and
application development are also clients.
Mid tierContains components and add-in services that run on a web server,
enabling users to view applications on the web.
Server tierContains the AR System server, which controls workflow

processes and access to databases and other data sources in the data tier. This
tier also contains server-side applications (such as Approval Server,
Email Engine, and the BMC Remedy Flashboards server) and the C and Oracle
Java plug-in servers with plug-ins.
Data tierContains database servers and other data sources that can be
accessed by the AR System server. The database server acts as the data storage
and retrieval engine.
Concepts Guide
Figure 1-2: AR System architecture
15
AR System clients
AR System clients can be broadly divided into user clients and developer clients.
User clients
The user clients use standard interfaces for their respective environments:
Table 1-1: User clients
User client
Platform
Description
Browsers
Provide a user
interface to
AR System
applications
through the
mid tier
Can be used for these functions:
BMC Remedy User
BMC Remedy Alert
Provides a
Windows-based
user interface to
AR System
applications
Windows
Submitting, searching for, and modifying

requests
Charting data
Generating reports
Receiving and responding to AR System
notifications
Performing administrative tasks such as
license management and AR System server
configuration
Sometimes considered a desktop pager, this

client notifies users about events by flashing an
icon, beeping, playing a sound file, running a
process, or opening a message window. For
example, it can display a message (an alert) to
notify service desk personnel that a reported
problem has been assigned to them.
Note: A similar functionality is available
through browsers. In browsers, alerts are

displayed in the Alert List form, which can be
refreshed automatically at specified intervals
or manually at any time.
16
Concepts Guide
Developer clients
The developer clients are used to create, modify, and extend AR System
applications:
Table 1-2: Developer clients
Developer client
Description
BMC Remedy Developer Studio
Used to create and modify all the components of an

AR System application, such as forms and workflow
elements.
Used to load external data into AR System forms. For

example, employee information can be extracted
from a human resources application and loaded into
the People form as a batch process, eliminating the
need to retype data. This client is also used to import
AR System data from one AR System server to
another.
BMC Remedy Migrator
Used to migrate applications, objects, and data

between servers, servers and files, or files. This client
reduces the difficulty and time required to
synchronize AR System servers in development and
production environments.
Note: For limitations on using BMC Remedy Migrator
with other BMC applications, see the BMC Remedy

Migrator Release Notes on the Customer Support
website (http://www.bmc.com/support).
Integration clients
BMC and its partners also offer the following tools for expanding the capabilities
of core AR System. These tools act as clients of AR System.
BMC Atrium Integration Engine (AIE)
BMC Remedy Knowledge Management
Network management platform integration accessories
Systems management integration utilities
See Chapter 5, Extending AR System.
17
AR System mid tier

BMC Remedy Mid Tier translates client requests, interprets responses from the
server, handles web service requests, and runs server-side processes that provide
AR System functionality to web clients.
For example, unlike BMC Remedy User, a browser is a generic client that has no
inherent knowledge of applications that run in it. By acting as an interpreter, the
mid tier enables a browser to become a fully functional AR System client.
The mid tier requires a supported Oracle JavaServer Pages (JSP) engine. For
example, you can install the Apache Tomcat servlet engine with the mid tier. For a
list of other supported JSP engines, see the BMC Remedy compatibility matrixes
on the Customer Support website (http://www.bmc.com/support).
AR System server
The AR System server processes all data entered through a client. As the workflow
engine between client and database, the server writes data to the database when a
request is created and retrieves data from the database when a client requests it.
The server verifies that a user has permission to perform each transaction, thereby
enforcing any access control defined in an application. The server also
continuously evaluates the data in the database and each transaction to determine
whether the server should perform workflow. The server might also perform
workflow on a timed basis. See Chapter 3, Workflow.
The AR System server communicates with the mid tier, AR System clients, and
external applications by means of a well-defined API. The server is available for
each of these operating systems:
Hewlett Packard HP-UX
IBM AIX
Linux (Red Hat and Novell SuSE)
Microsoft Windows Server
Oracle Microsystems Solaris
NOTE
For the most accurate information about supported platforms and software, always
see the BMC Remedy compatibility matrixes on the Customer Support website
(http://www.bmc.com/support).
Server groups
To provide scalability and increase reliability, you can connect a group of
AR System servers to the same database and manage them as a unit by configuring
a server group. Server groups act as a single server to support the applications that
they run. Servers in the server group can be configured to spread the load of shared
services, and they can provide backup to each other to ensure that those services
are always available.
18
Concepts Guide
Database servers
AR System uses standard relational databases to store and retrieve data.
Architecturally, the database server processes are completely separate from the
AR System server processes. Physically, the database server processes can run on
the same computer as the AR System server or on a different computer.
Because the AR System server manages all workflow, applications are
independent of the database. Therefore, applications created on an AR System
server running one type of database can easily be moved to a server running a
different type of database. BMC provides a simple export/import utility for this
purpose.
AR System can use any of these database platforms:
IBM DB2
IBM Informix Dynamic Server
Microsoft SQL Server
Oracle
Sybase ASE
NOTE
For the most accurate information about supported platforms and software, always
see the BMC Remedy compatibility matrixes on the Customer Support website
(http://www.bmc.com/support).
AR System workflow components can search for records (requests) in the
AR System database and act on the results of the search. Clients can use the
following types of searches:
Query-by-example (QBE)
Advanced search
Predefined
Recent
An administrator can create and store searches that are commonly performed by
users. A user can define personal searches for forms to which the user has access.
AR System can also work with data stored in external databases and other data
sources that are not managed by AR System. AR System accesses these data
sources through view forms. In addition, AR System can use AR System database
connectivity (ARDBC) to work with data not stored in databases as if the data were
locally owned.
19
Heterogeneous environment provides flexibility

Because the multiple layers of AR System are independent of one another, you can
combine operating system platforms to fulfill different functions. The
heterogeneous environment enables you to mix and match client and server
platforms. For example:
BMC Remedy Developer Studio on a computer running Windows can manage

forms on a UNIX or Linux server.
Browsers can use a Windows-based mid tier to access forms on a UNIX server.
An AR System server on Windows can interact with a database on UNIX.
Distributed environments provide scalability

Use BMC Remedy Distributed Server Option (DSO) to build large-scale,
distributed environments that behave like a single virtual system. DSO enables
you to share common information among servers and to keep that information
consistent.
For example, as illustrated in Figure 1-3 on page 21, you can transfer copies of a
request to other servers and ensure that any changes made to the copies are also
made to the original request. The way that you define the processes for
transferring information is similar to the way that you define business processes
for an application. First, managers at each site must agree on what information to
transfer from one application to another, what conditions drive transfers, and
which sites control the ability to update a record. An administrator at each site then
uses DSO to implement these decisions.
20
Concepts Guide
Application components
Figure 1-3: AR System in a distributed environment
AR System provides extensive authoring capabilities for applications built for web
and Windows environments. Applications developed with BMC Remedy
Developer Studio are fully customizable and extensible. You can add your own
fields, objects, and templates to any application, whether it was created by you,
purchased from BMC, or acquired from a third party.
This section introduces the main components of an AR System application.
FormThe main AR System application component that users interact with is a

form. Each form is composed of fields. A field can be a unit of information, such
as an employees last name, or it can be a visual element, such as a line or a box.
You can design different field arrangements, or views, of forms for different user
functions. When a user fills in the fields and saves the data, the system creates a
request to track. In database terms, each request is a record.
You can bundle related forms into an application. For example, a human
resources application might include forms for basic employee data, health
benefits, and salary information. You can deploy the application to multiple
servers to make it accessible to employees in different locations. You can also
display your application on the web to allow access from a browser on any
platform, as shown in Figure 1-4 on page 22. See Chapter 2, Forms and
applications.
21
Figure 1-4: Console application viewed in a browser
22
MenuMenus are lists that you create to guide the user in entering information
in fields on forms. A menu can contain all possible values for a field, or it can
contain some possible values, enabling users to enter text that is not on the
menu. You can design dynamic menus, which change their contents based on
the data already entered in the form. See Field menus on page 34.
WorkflowWhile forms provide the mechanism to structure data capture and

menus offer options for specific field data, additional componentsactive links,
filters, and escalationsact on the data to automate business processes, or
workflow. These components trigger actions in response to execution options that
you define. In AR System, workflow generally refers to the operations triggered
by these components, but AR System also addresses the broader meaning of
workflow, which consists of the processes that your organization uses to run
itself. See Chapter 3, Workflow.
Concepts Guide
Active linkAn active link is an action or group of actions performed on the

client. Active links are triggered by user actions in a form. They can be used
to perform a variety of tasks, such as giving quick responses during data entry
and auto-filling fields. For example, an active link can verify a value entered
in the Employee ID field of a request and then pull information from a
supporting People form to fill in other fields on the request, such as
Requestor Name, Department, and Phone Number, dramatically reducing
the time required for support staff to fill out a request.
An active link guide is a group of active links. Because active link guides run
on a client, they can augment training by leading users through the steps
necessary to fill in one or more forms to accomplish a specific task. For
example, when an employee clicks a Request Business Cards button on a
human resources form, an active link guide might open a business cards form
and then display input instructions, field by field, until the card request is
complete and ready to submit. Active link guides can also be used as
subroutines to accomplish common tasks.
FilterA filter is an action or group of actions performed on the AR System

server. Filters are used to enforce business rules and to ensure system and
data integrity. As the server processes a request, the filters associated with
that form and action evaluate the data in the request. For example, you can
verify the values in a completed form by using a filter to compare them
against your business rules and return an error if the request violates any of
those rules.
A filter guide is a group of filters that can be used as a subroutine in workflow.
Because filter guides run on the server, they cannot be used like active link
guides to lead users through a form.
EscalationAn escalation is an action or group of actions performed on the

server at specified times or time intervals. Basically, an escalation is an
automated, time-based process that searches for requests that match certain
criteria at specified times and takes actions based on the results of the search.
For example, an escalation can trigger AR System to notify the next level of
management if a problem is not assigned to a technician within one hour of
submission.
Preserving customizations with overlays and custom objects

AR System 7.6.04 introduces the following features that streamline the
customization process and ensure that your changes are not lost when an
AR System application or server is upgraded:
OverlaysAn overlay is a copy of an AR System object that is used in place of

the origin object. All out-of-the-box AR System application and server objects in
release 7.6.03 or earlier and objects created in the Base Development mode of
BMC Remedy Developer Studio in this release are origin objects.
Custom objectsA custom object is a stand-alone object created by an

AR System user. Objects created in the Best Practice Customization mode of
BMC Remedy Developer Studio are considered custom objects. Upgrades do
not modify or destroy custom objects.
23
These features protect your business investment in customizations by providing

the following benefits:
Enforce best practice development in BMC Remedy Developer Studio.
Preserve customizations during upgrades of AR System servers, components,

and applications.
Enable you to find all your customizations quickly and easily.
For more information, see the Form and Application Objects Guide, Customizing
objects, page 119.
In addition, the Best Practice Conversion utility enables you to convert pre-7.6.04
customizations to overlays or custom objects. See the Installation Guide,
Preserving pre-7.6.04 customizations, page 116.
How application components work together

This section uses the Example of a service desk solution on page 12 to illustrate
how the components of an AR System application work together.
In the example, when Ramona entered her telephone number into the Telephone
# field, the following sequence occurred, as illustrated in Figure 1-5 on page 25:
Step 1 An active link searched the Employee form to retrieve the name, configuration,
and location associated with the telephone number.

Step 2 After Ramona finished entering information into the form and submitted it, filters
triggered an external paging system integrated with AR System to notify Becky

that Ramonas printer was not working.
Step 3 Becky fixed the problem.
Step 4 Becky changed the status of the request, and a filter notified Ramona that her
problem was solved.
24
Concepts Guide
Administrator responsibilities
Figure 1-5: Automated workflow example
If the situation had been flagged as an emergency and no one was assigned to the
request within an hour, an escalation would have paged all required support
personnel, and a filter would have sent Ramona an email message informing her
of the status of her request.
Administrator responsibilities
Typically, AR System administrators are responsible for some or all of these tasks:
Installing AR System software
Defining their organizations work processes and business rules
Determining how to allocate server and database resources
Managing AR System access control by assigning permissions for AR System

applications and their components
Maintaining AR System by adding and deleting users, groups, and roles;

backing up AR System servers; importing data from other systems; and so on
25
Developer responsibilities
Typically, AR System developers are responsible for some or all of these tasks:
Creating an AR System application that reflects a set of work processes and

business rules, or working with a consultant to create an application
Localizing an AR System application for use in other languages or countries
Modifying an AR System application to reflect changes in the organizations

work processes
Programmer responsibilities
Typically, AR System programmers are responsible for some or all of these tasks:
26
Writing plug-ins and custom clients that use the AR System C API, Java API, or
Java plug-in API
Integrating external applications with AR System
Concepts Guide
Chapter
This chapter describes forms and how forms are used in applications. It also
describes localization features for applications.
About AR System forms (page 28)

Types of fields (page 32)
Field menus (page 34)
Forms in applications (page 35)
Localized applications (page 36)
Chapter 2
27
About AR System forms

Forms are the foundation of AR System. A form captures and displays information
and a set of forms can be grouped into an applications.
For example, a service desk form captures information needed to fix a users
computer problem. A purchase requisition form captures the information needed
to purchase an item. Figure 2-1 illustrates an AR System form.
Each form contains fields. Some fields, known as data fields, capture a certain type
of information, such as a user name or problem details, and have their own set of
rules about who can view or modify that information (see Types of fields on
page 32). Some fields can have attached menus that help users fill in the form (see
Field menus on page 34).
Figure 2-1: Example AR System form
28
Concepts Guide
Each form in an application is like a template to capture or present information.

When a user opens a form to perform a task, the template is presented to help the
user complete the task. When the form is filled in and submitted to AR System, the
system creates a request, also known as a record in database terms.
Forms are stored as tables in the database. Each data field on the form corresponds
to a column in the table. A request corresponds to a row (or record) in the table.
Figure 2-2: A form from the view of the database
Types of forms
You can create the following types of forms, as illustrated in Figure 2-3 on page 30:
Table 2-1: Form types
Form type
Description
Regular
Information submitted through and displayed in regular forms is stored in database tables.
These forms are typically the main forms in applications. They are also called data forms.
Display-only
These forms contain display-only fields that enable users to accomplish specific tasks. These
forms are typically used to create control panels, which are launch points from which users
choose other tasks. Display-only forms can also be used to create dialog boxes, which prompt
users as they fill out a form. Display-only forms do not contain data, so no database tables
are associated with them.
Join
These forms are composed of fields from two or more existing forms. Join forms are useful
when you have information in multiple forms that you want to display in a single form. Join
forms do not contain data, so they have no database tables associated with them. The data is
contained in the underlying forms that make up the join form.
View
These forms enable users to connect to database tables created outside of AR System. These
forms enable you to bring data from other applications that is stored in a database into
AR System without replication or programming.
Vendor
These forms enable users to connect to external data sourcessuch as text files, spreadsheets,
or database tables residing on local or remote serversthrough an ARDBC plug-in. Some
programming is required to connect to the data source.
Chapter 2
29
Figure 2-3: Types of AR System forms
Form views
A view is a visual representation of a form. To reuse a form for diverse groups
while accommodating each groups unique needs, you can create a different view
of the form for each group. This enables you to customize the interface of an
AR System application so that each group sees the system as its own.
30
Concepts Guide
You can create as many views of a form as you need. For example, you can provide
views customized according to the following criteria:
Users roles (requesters, managers, and so forth)
Size of the screen (for example, laptop or desktop)
Language or locale (for example, Brazilian Portuguese)
When creating form views, you can
Change the layout of the form
Use different fields in different views
Tailor views to provide the best result in the target display environment, such
as browsers
Use terminology or language specific to the group using the view
Reports based on form data

Using the AR System Reporting Console, which provides a single interface for all
reporting functions, users can create and run nicely formatted reports based on the
data stored in AR System forms. The new Web report type is supported by
reporting components that are installed with BMC Remedy Mid Tier.
In addition, users can use the traditional AR System reports or Crystal Reports, a
reporting package that you can integrate with AR System.
Users can also use the Reporting Console to run existing Web reports, AR System
reports, and Crystal reports, including those defined by others or installed with
BMC applications if they have the necessary permissions.
Chapter 2
31
Types of fields
Fields enable you to control how information is captured and displayed in forms.
You can include the following types of fields in forms:
Table 2-2: Field types
Field type
Description
Data
Contains data values stored in database tables. You can set these characteristics of data
fields:
Whether users can access the field and, if so, whether they can only view the field or
also change its contents.
The type of data that the field can contain (such as characters, integers, dates, or times).
The amount of information that the field can contain (field length).
Whether the field is visible or hidden.
Whether the field is enabled or disabled.
Whether the field is required, optional, or display-only. (A display-only field is a
temporary field for which no space is allocated in the database.)
Where the field appears on the form.
How the field is displayed (for example, its label and physical appearance).
How information is entered into the field (for example, by typing or by selecting items
from a list or a menu).
The fields default value.
Whether fields are indexed for faster searches.
Table
Displays data from other requests in the context of the current request. Table field styles
are list view, tree view, cell-based, results list, and alert list.
Attachment
Attaches files to requests.
View
Provides a browser window in a form. The browser can display any URL, HTML
content, or file format (including contents of attachments) that is compatible with a
browser.
Data visualization
Augments AR System with HTML-based contentsuch as web pages, flashboards, and

other graphicsthat can interact with the fields parent form through workflow.
Application list
Displays a list of entry points. An entry point is a link that users click to open forms on the
correct server in the required mode (New or Search).
AR System automatically generates the contents of the application list. The entry points
that a user sees in the list are only those to which the user has access.
Any form that contains an application list field can be used as a home page. A home page
is a single point of access into AR System.
Horizontal and
vertical navigation
Enables users to navigate to the correct screen in an application quickly and easily.
Control
Triggers active links. Control fields include buttons, menu items, and toolbar buttons.
Panel
Organizes other fields on forms into smaller containers that can be hidden when not
needed. Panel fields can have various formats, such as tabbed, collapsible, splitter, and
accordion.
Trim
Adds boxes, lines, and text to enhance the visual appearance of forms.
32
Concepts Guide
Types of fields
You can add as many fields as you need to a form (within the limits of your
database) to capture and display the information required by your application.
You can use workflow to manipulate the attributes of fields. For example, you can
set permissions for a group of trim fields or active link control fields so that they
are inaccessible to certain groups of users, or you can add tabs in a panel field that
are visible to some users (such as managers or support staff) but not to others.
Characteristics common to all fields

All fields in AR System share these characteristics:
They can be disabled (dimmed) or hidden.
They have a unique field ID and field name.
They can be used in workflow.
They can have context-sensitive help associated with them to help users learn
more about them.
Their display properties (including their location on a form and their

appearance) can be changed.
Permissions can be set to specify which users can access them.
AR System automatically records their history, including their owner (the user
who created them), the user who last modified them, and the date and time that
they were last modified.
Core fields in a regular form

A regular form automatically contains these core fields.
Request IDUnique tracking number assigned to each request by AR System.
SubmitterLogin name of the user who submits a request.
Create DateDate and time that a request is created.
Assigned ToPerson assigned to handle the request.
Last Modified ByUser who last modified the request.
Modified DateDate and time that the request was last modified.
StatusCurrent status of the request.
Short DescriptionBrief description of the request.
Status HistoryTime the requests status was last changed and who changed
it. This field does not appear in forms. To view the information in this field,
users must display a request and choose View > Status History.
These fields provide basic capabilities that most application designers need. For
more information, see the Form and Application Objects Guide, Core fields,
page 472.
Chapter 2
33
AR System has templates for blank forms and forms with core fields. You cannot
delete core fields from a form created with them, but you can hide them from a
users view and change their labels, location, and appearance.
The following table shows the meaning of the field label styles:
Table 2-3: Field label styles
Style
Description
Bold
Field requires a valuedefault, user-entered, or from workflow

when a user submits a request.
Italic
Field is automatically populated by AR System.
Plain
Field is optional. Users can enter information in it or leave it empty.
Field menus
Field menus help users enter data and ensure that the data is consistent. You can
attach a menu to any character field (character fields are data fields that hold
alphanumeric characters). Menus can be statically defined, dynamically built by
searching AR System databases and external databases, or read from text files
written by other applications.
Menus are separate objects stored independently of a form. This means that you
can create a single menu and use it for multiple forms and for multiple fields in one
form.
AR System defines these types of menus:
Table 2-4: Menu types (Sheet 1 of 2)
34
Menu type
Description
Character
Stored and maintained as a list of items in AR System. These menus

are useful for fields that have a predefined series of choices that
change infrequently. They can have submenus.
File
Contains items that are created and maintained in a plain text file. The
file can be stored on the system where BMC Remedy User is running
or on the AR System server. File menus are convenient when you do
not want to store the data in the AR System database. To change a file
menu, simply update the file; the changes are applied when the menu
is refreshed. File menus can have submenus.
Search
Retrieves information from requests stored in AR System databases.

The information is used to build a menu dynamically in the current
form. Search menus are often used when the choices in a menu depend
on values entered in fields on the current form.
Concepts Guide
Forms in applications
Table 2-4: Menu types (Sheet 2 of 2)

Menu type
Description
SQL
Also retrieves information from databases, but the databases can be

outside AR System. When you access an SQL menu, AR System uses
an SQL query to extract the data and then generates the menu from
that data.
Data dictionary
Retrieves lists of fields and forms from an AR System server. These

menus are useful for creating special configuration interfaces. They
are generally not used to help users perform their work.
Forms in applications
An AR System application is a server object that contains references to one or more
forms. When an application references a form, AR System automatically includes
all the workflow and other components (such as menus) associated with the form
in the application.
Sometimes a single form can contain all of an applications functionality. For
example, a small application that tracks product defects can use a single defecttracking form to capture and display all required information.
Most applications, however, need several forms to capture, track, and organize
information. One or more forms make up the applications main forms (sometimes
called primary forms) that users interact with directly. Often, the main form is a
console that serves as a navigation and information center. The application can also
have other forms, called supporting forms, which supply information needed by the
main forms.
You can create the following types of applications:
Deployable applications are designed to be used in multiple server

environments. These applications use permissions based on roles defined in the
application. When the application is deployed, the administrator maps the roles
to groups on the local server. Other features available to deployable applications
include the ability to gather statistics about the application and to map the same
role to different groups for different application states, such as test or
production.
Local applications use permissions based on groups defined on the local server.
Therefore, these applications are usually used on a single server.
For information about groups and roles, see Chapter 4, Access control.
Chapter 2
35
Localized applications
Localization is the process of customizing an application for use in various
languages, countries, and cultures. AR System provides an internationalized
environment for building, testing, and localizing applications.
A locale describes the language, country setting, and other characteristics of the
local systems user interface. You can create an AR System application to run in a
particular locale, or you can make your application simultaneously available in
multiple locales.
The development environment enables you to localize all aspects of the user
interface:
Language used for labels, messages, help text, reports, menus, and any other
words that are part of a forms user interface
Separator symbol for decimal numbers that include a fraction
Separator symbol for numbers greater than 999
Format for dates and times
Layout, colors, and images
You can store each localized version of a form as a view. Therefore, the same
application can provide separate user interfaces (views) for British English,
Australian English, Mexican Spanish, and Peruvian Spanish.
NOTE
Although the user interface is tailored to each users locale, the data and workflow are
the same for all users. Therefore, you need to agree on the language for the data
before the application is made available.
The localization features are automatic for the user and easy to implement for the
application builder. To localize an application for a given locale, an administrator
need create views only for that locale and add corresponding messages to the
message catalog. Utilities are available to assist with this work. See the Form and
Application Objects Guide, Localizing AR System applications, page 577.
36
Concepts Guide
Chapter
Workflow
This chapter describes the workflow components of AR System.

Workflow in general and in AR System (page 38)

Types of workflow components (page 38)
Collections of workflow components (page 40)
Workflow actions and execution options (page 40)
Workflow qualifications (page 46)
For detailed information about workflow, see the Workflow Objects Guide.
Chapter 3 Workflow
37
Workflow in general and in AR System

The function of workflow is to process the data captured in forms in accordance
with your business needs. In AR System, workflow automates your companys
processes through the use of active links, filters, and escalations. In general, workflow
can be defined as the set of processes that your company uses to run itselffor
example, tracking defects or administering employee benefits.
You use the workflow components of AR System to enforce business rules in a
variety of ways, including notifying people of events, escalating problems to a
higher level, automatically routing information, and checking whether key data is
correctly entered.
For example, if your organization decides that purchase orders for amounts above
a certain level need director approval, you can design workflow that allows only
correctly approved purchase orders to be automatically forwarded to the
purchasing department.
You define workflow by specifying the actions that active links, filters, and
escalations should perform under specified circumstances. The circumstances are
called execution options. You can create workflow components for a single form, or
you can share workflow components with multiple forms. (Workflow components
cannot exist independently of forms.)
Some of the actions that workflow components can take to automate processes and
ease data entry include:
Overriding user-entered values by changing them to values that you specify
Manipulating a form (for example, enabling or disabling fields, or changing

menus associated with fields)
Checking for errors
Opening new windows for data entry or display
Communicating with users by means of onscreen messages or notifications sent

by email, BMC Remedy Alert, or other methods
Running an active link guide or a filter guide as a subroutine (a predefined

sequence of commands)
Types of workflow components

This table summarizes how and where you use filters, active links, and escalations:
Table 3-1: How and where workflow components are used
38
Component
Triggered by
Where action is performed
Active link
Events
Client
Filter
Events
Server
Escalation
Time
Server
Concepts Guide
Types of workflow components
Workflow based on events versus time

Filters and active links are triggered by events, such as a user action or a change in
the state of some data, whereas escalations implement time-based business rules.
For example, a filter can notify a support manager whenever a request is submitted
with a priority of High or Critical. The submission of the request is the event. Other
events that can trigger filters are updating, deleting, and retrieving requests.
Actions that can trigger active links include opening or closing a window,
displaying a request, clicking a button on a form, pressing Enter when the cursor
is in a field, or selecting a menu item.
Escalations are triggered by the passage of time. The trigger (or execution option)
can be either absolute time, such as every day at 2:00 p.m., or a time interval,
such as one hour between escalation runs. For example, an escalation can warn
a group of users that in one hour their manager will be notified that a problem has
been unsolved for too long.
Workflow running on clients versus servers

Active links are executed on the client side in response to actions that users
perform in forms, whereas filters and escalations are executed on the server.
For example, active links can change how a form looks or behaves, validate data
entered by users, or use data in a form to find other data for the form. Unless an
active link queries the AR System server for information or runs a process on the
server, it can complete its operation without sending a request to the server. This
capability helps decrease overall network traffic and improves the performance of
an application.
Filters and escalations implement business rules by examining newly created or
changed requests and taking actionssuch as changing data in the request,
creating other requests, or sending notificationsbased on the new data and the
business rules. For example, if your business wants to avoid handling purchase
orders that are not properly approved, you can create a filter that stops AR System
from processing such purchase orders after they are submitted to the server and
then notifies the requester accordingly.
Actions associated with filters and escalations take place after the transaction is
transferred to the server for processing. Then, processing can return to the client,
where more active link actions can take place.
NOTE
API calls to the server trigger filters but not active links. If a business rule must be
fired on any input (including user input and input from an integrated process
using an API), the business logic must be in both an active link and a filter.
Chapter 3 Workflow
39
Collections of workflow components

You can collect active links and filters and run them as procedures. These
collections are called active link guides and filter guides.
The workflow components in guides are organized in a processing sequence.
Using guides enables you to give a name to a set of workflow operations that
accomplish a specific task.
In addition, interactive or navigational active link guides can interact with users by
requesting information and then waiting for input. This enables you to create tasks
that guide users through application processes in a way similar to wizards.
Workflow actions and execution options

The basic questions about workflow are What can I do, and when can I do it? The
actions that workflow can take are the what, and the execution options are the when.
For example, users could click a button labeled Display My Active Cases to
display a list of all requests assigned to the user.
Figure 3-1: Example of basic workflow
You can refine execution options by specifying a qualification that must be met
before an action is taken. Qualifications are often required to ensure that workflow
actions apply only to certain requests. In addition, carefully designed
qualifications make workflow components more efficient and powerful.
You can specify a primary action and an alternative action. If an operation meets
the qualification, the primary (if) action is performed; if not, the alternative
(else) action is performed, as shown in Figure 3-2 on page 41.
40
Concepts Guide
Figure 3-2: Example of workflow with qualification
Workflow actions
The following table lists some of the actions that active links, filters, and escalations
can perform. For a complete list, see the Workflow Objects Guide , Types of
workflow actions, page 75.
Table 3-2: Workflow actions (Sheet 1 of 3)
Action
Description
Change Field
Changes the appearance of fields. For example, a

Change Field action can perform one or more of
these actions:
Close Window
Active link Filter
Escalation
Moves the cursor or keyboard focus to a field.

Hides or displays a field. For example, an active
link might hide all fields related to telephone
problems when users report network problems.
Changes a fields accessibility to read-only,
read/write, or disabled.
Changes the color of a field label or trim text.
Changes the menu attached to a character field.
For example, if a form for scheduling a meeting
has a field for the building, the menu of meeting
rooms attached to the meeting room field might
change to match the specified building.
Refreshes the data in a table field.
Changes the label of a field.
Expands or collapses a collapsible panel field.
Closes the current window.
Chapter 3 Workflow
41

Action
Description
Message
Prompts with advice, gives reactive information,

warns of a particular situation, or presents an error
message and stops the processing of current
workflow.
Active link Filter

+
Escalation
Active links execute on the client, so they can

display messages immediately. For example, when
users fill in a particular field, an active link could
warn that a related field must be filled in first.
Active link messages can appear in different
display formats, such as a dialog box, the Prompt
Bar, or a tooltip.
Filters execute on the server, so they are useful for
checking entire transactions and sending error
messages or informational messages. For example,
a filter could display a message indicating that the
support staff has been notified about a problem.
Notify
Sends event notifications to users or groups by

email, BMC Remedy Alert, or a custom
mechanism, such as a Windows service that pages
users. For example, a filter might notify support
staff when they are assigned a request. Or an
escalation might notify the service department
when an asset warranty has expired.
Open Window
Opens a window of any type in the client. The

action can open a New window and load some
default data. Or it can open a Modify window with
requests matching a specified qualification.
This action can also open a dialog box. Data can be

passed between the dialog box and the window
that calls it. Processing of active links from the
calling window is suspended until the dialog box
interaction is completed.
Push Fields
Changes the values of fields in another request to

the values in the current request (that is, it pushes
the values from the current request to another
request). This action can also change the value to a
keyword or a function.
You can use Push Fields to set values in related
requests or to create requests that are associated
with the current one. For example, you can use this
action to create multiple work orders for a
telephone connection, a network address, and new
furniture when an employee is hired.
Run Process
42
Runs a separate process (program) on the server for

filters and escalations or on the Windows client or
server for active links. For example, a filter can send
a page, or an active link can launch a browser on a
users desktop.
Concepts Guide

Action
Description
Active link Filter
Escalation
Service
Works with an AR System web service to obtain

external services or with a Set Fields filter action to
consume an internal AR System service.
Set Fields
Sets fields on a form to specified values. For

example, a filter can automatically set the Status
field to Assigned every time a name is entered into
the Assigned To field.
The value set in a field can be static (always the

same), a keyword value, or a value retrieved from
another data source.
Workflow execution options

Execution options determine when workflow runs. For active links and filters, you
specify what event triggers the workflow; for escalations, you specify the
execution schedule for the workflow. For all workflow components, you can refine
the execution option by adding a qualifying statement that tells the system which
set of actions to run if the additional criteria are met and which set to run if the
criteria are not met.
Active link and filter execution options

The following table lists examples of execution options for active links and filters.
For a complete list, see the Workflow Objects Guide, Defining workflow execution
options, page 37.
Table 3-3: Execution options for active links and filters (Sheet 1 of 2)
Execution option
Description
Button/Menu Field
Executes when a user selects the button or menu item

associated with the active link.
Gain Focus
Executes when a user or a Change Field action moves the

cursor to a field.
Display
Executes after a request is loaded into a form but before the

request appears in the Details pane.
Hover on Field
Executes when a user hovers the mouse pointer over a field,

field data, or a field label. To display tooltips, use a Hover
execution option to trigger a Message action.
Lose Focus
Executes when a user or a Change Field action moves the

cursor out of a field.
Menu Choice
Executes when a user chooses an item from a character menu

associated with a specified field.
Hover on Data
Hover on Label
Active link Filter
Chapter 3 Workflow
43
Table 3-3: Execution options for active links and filters (Sheet 2 of 2)
Execution option
Description
Active link Filter
Modify
Executes after a user modifies an existing request but before

the request is sent to the AR System server (for active links)
or to the database (for filters). An active link with this
execution option does not run during a Modify All
operation.
Service
Enables filters to be called by the Service action.
Submit
Executes after a user submits a new request but before the

request is sent to the AR System server (for active links) or to
the database (for filters).
Table Refresh
Executes when a user updates a tables contents by loading

the field, sorting, refreshing, or displaying the previous or
next part (chunk) of the table.
Window Open
Executes when a user opens a form or dialog box or changes

a form to a different mode. This is especially useful for
establishing initial environments. It executes before any data
is loaded into the window.
+
+
Execution options and user actions

Some execution options depend on how a user interacts with fields on the form.
For example, if the user does not click a particular button, that active link does not
fire (the user controls whether the active link fires). Use user-controlled
execution options to provide additional helpful information, such as a list of
nearby printers.
Active links that are not under a users control, however, fire whenever the user
finishes a task. That is, if the user follows the normal steps, from opening a window
through closing the window, the active links not under explicit user control always
fire. (Of course, if a user does not submit or modify the request, the active links that
fire on Submit or Modify do not execute.) Use execution options that are not
controlled by users to ensure that consistent, complete data is maintained
regardless of whether users perform certain actions. For example, to guarantee that
every submitted request includes the host name, an active link could retrieve the
host name of the client and copy it into a field in the form whenever a request is
submitted.
Execution order of active links and filters

Active link execution options have an implicit order in relation to one another and
to the interaction between the client and server. You can use this order to control
when the active link runs. For example:
44
If field values were required for workflow processing before a request is

displayed, you would set them on Window Open. However, to set any values
that you want the user to see when a request is displayed, you would use the
Display execution option.
An active link that runs on Window Open might check the users permission to
open a Modify All window and, if the user does not have permission, generate
an error message, preventing the window from opening.
Concepts Guide
More than one active link or filter can run on the same execution option. In this
case, you can specify the order that you want it to fire in relation to the other active
links or filters. One reason to do so is that the output of one active link can affect
another active link. By carefully ordering a group of active links, you can perform
very complex operations.
When active links and filters are bundled into guides, execution order within the
guides is ignored. Instead, workflow executes in positional order within a guide.
This enables a guide procedure to run without affecting the order of workflow
outside the guide.
Escalation execution options

In contrast to active links and filters, which react to events, escalations respond to
the passage of time. You can trigger an escalation at a specific time, such as every
Monday at 6 a.m., or at a time interval, such as eight hours after each run of the
escalation.
When the specified time arrives, the server searches for requests in the database
that meet the escalations qualification. If it finds any, the server runs the
escalations primary (if) actions for each matching request. If no requests meet
the qualification, the server runs the escalations alternative (else) actions, if
any, once. Figure 3-3 illustrates how escalations work.
Chapter 3 Workflow
45
Figure 3-3: How escalations work
An alternative (else) action for the example in Figure 3-3 might be to notify the
manager that all requests comply with the assignment rule. This action would run
only if no requests meet the escalation qualification.
Workflow qualifications
Qualifications in active links, filters, and escalations enable you to define the data
condition that causes the workflow component to take action.
You can use qualifications to check values in fields, the amount of time that has
passed since a specified event occurred, and many other factors. For example, a
qualification might check whether the priority of a request is High or Critical or
whether the day is a weekend day.
46
Concepts Guide
Workflow qualifications
Qualifications with active links and filters work differently from qualifications
with escalations:
Active link and filter qualifications control which actions, if any, are run for the
current request. For example, an active link can run actions whenever a specific
field is filled in (execution option), or it can run actions whenever the field is
filled in and the value in the field is invalid (qualification).
Escalations are run whenever the scheduled time arrives. The qualification is an
essential part of most escalations, not simply a refinement. It determines the
requests on which the primary (if) escalation actions are run. Without a
qualification, the primary actions are run on every request (record) in the form
to which the escalation is attached. For example, if an escalation simply sent a
notification every hour (execution option), the notification would be
meaningless. A meaningful escalation, however, might check every hour
(execution option) whether three or more hours have elapsed since a request
was submitted and the request is unassigned (qualification), and then send a
notification listing the unassigned requests to a manager. If no requests meet the
qualification, the escalation might specify alternative (else) actions that are
executed once, such as sending the manager a notice that all requests comply
with the assignment rule. For an illustration of how qualifications are used in
escalations, see Figure 3-3 on page 46.
For filters, the qualification can check the value of a field in the database, in the
current transaction, or both. This makes it possible to check whether the value of
the field is changing. For example, if you have a business rule that service desk
requests can be closed only if they have been fixed, a filter could check all
transactions that change the status of a request to Closed. If the database value of
the status is Fixed, the request can be modified; otherwise, the change is not
allowed.
Keywords in qualifications
A keyword is a variable whose value is defined by AR System. Keyword names are
uppercase and enclosed in dollar signs. For example, $USER$ represents the name
of the user who is currently logged in, $TIMESTAMP$ represents the current date
and time, and $OPERATION$ represents the operation currently in progress.
Keywords are used to build qualifications. Keywords can be used almost
anywhere a qualification can be defined or a value specified:
Defining qualifications for search menus and for workflow. For example,
workflow can check the value of the keyword $OS$ to ensure that the operating
system can run a process that you specify in workflow.
Specifying a value in the Set Fields action.
Defining searches and macros.
For a complete list of keywords, see the Workflow Objects Guide, Keywords,
page 221.
Chapter 3 Workflow
47
48
Concepts Guide
Chapter
Access control
This chapter describes access control in AR System.

About access control in AR System (page 50)

User and group access (page 50)
Role-based access (page 53)
Multitiered access control model (page 54)
How licensing affects access control (page 56)
Chapter 4
Access control
49
About access control in AR System

AR System provides a rich set of features that protect your data from unauthorized
access. In addition, it has a logical, multitiered access control structure that is
straightforward for you to implement and for users to understand.
Keeping information secure can be a major undertaking in client/server
environments. It is sometimes a balancing act for administrators. You want to
rigorously control who can access data, yet you do not want security to be so
complex that it intrudes on your user community or is difficult for you to
implement or maintain.
AR System enables you to meet these seemingly opposing security goals. It enables
you to control which users can access data and perform certain actions such as
modifying a request or triggering an active link. User access is determined by these
conditions:
The groups users belong to
The licenses users are granted
AR System uses a multitiered approach to control access at these points:
Server
Form (or table)
Field (or column)
Active link and active link guide
Request (or row)
This approach provides a wide range of control over data access, enabling you to
restrict access broadly at the highest levels (server and form) and narrowly at the
request and field levels. Because you can refine your data access criteria so
precisely, you can use a single form for many different purposes simply by setting
the appropriate permissions.
User and group access

Individuals who need to access AR System are registered as users by an
administrator. The administrator then assigns the users to access control groups.
Each access control group is defined for a particular server. An access control
group has permissions that determine whether and how its members can access
application components, such as forms, requests, fields, active links, and active
link guides. (Administrators can also set default permissions for each component
type so that whenever they create a component, selected groups automatically
have access to it.)
50
Concepts Guide
User and group access
Users are assigned to groups according to their need to access information. For
example, you might create a group called Employee Services Staff whose members
are permitted to view and change only certain fields in an Employee Information
form. You might have another group called Employee Services Managers whose
members are permitted to view and change all fields in the Employee Information
form, including salary information. You can also configure a hierarchical
relationship between groups to allow the parent group to inherit the permissions
of the child group.
AR System has predefined groups that perform specific functions (see Types of
access control groups on page 52). In addition, you can create any number of
custom groups in AR System to enforce access control. You can also permit
unregistered users to access AR System as guests. Guests are members of the
predefined Public group.
Chapter 4
Access control
51
Types of access control groups

This table lists the types of access control groups:
Table 4-1: Access control group types
Type of access
control group
Explicit
Description
Predefined groups1
A group to which you must

assign users.
Administrator
Sub Administrator
Customize
Custom groups2
Any regular and computed groups that
you create.
Regular groups are groups to which you
assign a specific list of users.
Computed groups are groups to which
users are assigned based on their
memberships in groups included in an
expression. For example, you can create
a computed group definition such as
(A AND B) OR C AND NOT D. This
computed group includes users who are
members of both groups A and B, or
members of group C, but not members
of group D.
Implicit
A group to which a user

automatically (or
implicitly) belongs by
virtue of the contents of
certain fields in a request.
You cannot assign users to
implicit groups.
Public
Submitter
Assignee
Assignee Group
Any dynamic groups that you create.

Dynamic groups use the contents of
special fields to determine group
membership.
All users are members of

Public. You use the other
types of implicit groups to
control access to requests
(row-level database
access).
1
2
AR System provides these access control groups.

You must add these access control groups to your system.
For more information, see the Form and Application Objects Guide, Defining access
control, page 21.
Additive permissions
Access control in AR System is additive. This means that each user in AR System
starts out with no access permissions. Administrators add users to access control
groups as needed. In this way, AR System implements strict access control:
administrators must make a conscious decision to add users to groups on a caseby-case basis.
52
Concepts Guide
Role-based access
Membership in multiple groups

Users often belong to multiple groups in an organization. They inherit permissions
from each of the groups to which they belong.
If a group has permission to access a form, field, request, active link, or active link
guide and a user belongs to that group, the user has access, even if the user belongs
to other groups that do not have access.
Figure 4-1: How permissions work
Role-based access
In deployable applications, access permissions are based on roles. Like groups,
roles have permissions to access forms, fields, active links, and so on. Unlike
groups, however, roles are defined for an application and are then associated with
groups on the server where the application is deployed.
Roles make deployable applications easy to install on a variety of servers. You
assign users to groups and then associate the groups with roles. This enables you
to install an application on servers that have different groups without redefining
the applications object permissions for each server.
NOTE
For simplification, user access is usually described in terms of group permissions. In
deployable applications, which use role permissions, user access is ultimately
determined by which groups are mapped to which roles.
Chapter 4
Access control
53
Multitiered access control model

AR System uses a multitiered approach to control data access. At each access level,
a users permissions are checked. If access is permitted, the user proceeds to the
next level. If access is denied at any point except active links and active link guides
(workflow), the user cannot proceed. (If access is denied at workflow, the user
might be able to proceed, but his data access capabilities will be limited.)
For example, if a user is denied access to a form, the user cannot see any fields
associated with the form. For another example, a users ability to access a request
depends on whether he belongs to a group that has access to the Request ID field.
Figure 4-2: Access control in AR System
54
Concepts Guide
Multitiered access control model
Access control levels

The access control model comprises the following levels:
Table 4-2: Access levels
Access level
Description
AR System server
Users must pass an initial checkpoint when they start an AR System client, such as a
browser or BMC Remedy User. At this point, users must enter a valid user name, a
password, and, as an option, an authentication string. AR System servers check the user
name, password, and authentication string each time a client requests a transaction,
such as when opening a form or changing a field.
Note: If your AR System server is configured to allow guest users, such users can log in
to the server without a valid user name or password. See the Configuration Guide,
Allowing guest users, page 64.
Form
As an administrator, you give groups access to forms according to each groups need to
view or change information in the form. Visible access enables users to access a form from
the Object List. Hidden access makes a form available only through workflow. Static
permissions inheritance and dynamic permissions inheritance properties control access to the
form for parent groups. If a group is not given access to a form, members of that group
cannot view the form or change the requests that it contains.
Field
You can control access to each field on a form, including nondata fields such as trim
fields, table fields, and active link control fields. You can make a field visible to users or
hide the field so that it is accessible only through workflow. For data fields, you also
specify whether a group can only view field information or also change it. If a group
cannot access a field, the field does not appear when members of the group open the
form.
Active link
In addition to controlling access to form and field data, you can control access to active
links, which trigger a variety of workflow actions. For example, you might allow
support staff to trigger several active links appropriate to their work but not allow other
users to trigger those active links.
Groups do not automatically have access to the field associated with an active link. You
must grant them access to the active link and to the field. For active links that fire when
users click a button or choose a menu item, the users must have access to both the button
or menu item and the active link to trigger the active link.
Active link guide
When you create an active link guide, you specify the groups that have access to it. To
access an active link guide, a user must have permission to each active link in the guide
and to the guide itself. If a user has access to all active links in a guide but not to the
guide, the guide does not appear.
Request
You can strictly control who can access requests associated with a form. For example,
you might want only managers to access requests with confidential employee
information. Or you might provide an outsourcing service in which you use AR System
as the central service desk for several companies, and you do not want one company to
see requests from another company.
Chapter 4
Access control
55
How licensing affects access control

In addition to obtaining a license to run the AR System server and other
components, you must specify a license type for each AR System user.
NOTE
AR System includes a setting that enables you to permit users who are not
recognized users to access to AR System applications as a member of the Public
Group. For more information, see User and group access on page 50.
Although licensing is not a component of access control, licensing can affect a
users ability to perform an operation that you grant her permission to perform.
For example, if a user is a member of a group that has Change permission to a field
but you did not give her the appropriate write license, she cannot change the field.
License types
You can assign the types of user licenses listed in this table:
Table 4-3: License types (Sheet 1 of 2)
License
Description
Read
Enables users to search for and display requests within their assigned permissions.
Administrators can configure the AR System server to enable users with Read licenses to
submit requests and to modify requests that they submit.
Restricted Read
Enables users to search for and display requests within their assigned permissions.
Administrators can configure the AR System server to enable users with Restricted Read
licenses to submit requests. But users with Restricted Read licenses cannot modify any
requests, including their own.
Restricted Read licenses do enable the same login account to access AR System from
multiple IP addresses simultaneously.
56
Concepts Guide
How licensing affects access control
Table 4-3: License types (Sheet 2 of 2)

License
Description
Fixed
Includes all the capabilities of a Read license, and also enables users (based on the
permissions of the groups to which they belong) to modify and save requests that they did
not submit. AR System administrators and subadministrators must have a Fixed license.
Other AR System users who consistently need to modify requests must also have Fixed
licenses.
A fixed write license is associated with a user name and is always reserved for that user.
Users who have a fixed write license can access the AR System server at any time.
Floating
Includes all the capabilities of a Read license, and also enables users to modify and save
data for requests that they did not submit based on the groups to which they belong.
Multiple users can use the same Floating licenses, one user at a time: they are available on
a first-come, first-served basis. This type of license is designed for users who occasionally
need to modify and save requests.
When a user who is assigned a Floating license logs in to AR System, the user is given a
Read license. When the user attempts to perform a search, modify, or submit operation,
AR System checks for an available Floating license, and the following occurs:
If a Floating license is available, the user is granted write access to requests. The user
retains write access until the Floating license is released (for more information, see
Releasing floating licenses on page 53).
If no Floating licenses are available, the user is notified and continues to use the Read
license until a Floating license becomes available.
Generally, Floating licenses are shared by all AR System users. You can, however, define
license pools to reserve a set of Floating licenses for a group of users. This enables you to
prioritize the availability of Floating licenses. For example, you can allocate a number of
licenses to department managers to make sure that they can immediately approve
essential requests. Users who do not belong to this group cannot acquire any of the
reserved licenses.
An AR System server provides three fixed write licenses and unlimited read and
restricted read licenses. You can purchase additional fixed write licenses and
floating write licenses from BMC or from an authorized reseller.
For more information about licensing, see the Configuration Guide, Licensing
AR System, page 35.
Chapter 4
Access control
57
58
Concepts Guide
Chapter
Extending AR System
The core AR System productclients (BMC Remedy Developer Studio and

BMC Remedy User), mid tier, and AR System serveris the foundation for the
BMC Remedy product line. Beyond the core environment, BMC offers add-on
products that provide additional services and capabilities. This chapter provides
brief overviews of these products.
In addition, third parties have developed a wide range of products for integration
with AR System. Some of the most popular integration areas are discussed in this
chapter.
AR System foundation products (page 60)

BMC Atrium products (page 61)
AR Systembased solutions (page 61)
Other BMC products (page 62)
Integration with third-party products (page 62)
Chapter 5
Extending AR System
59
AR System foundation products

These BMC Remedy products add functionality to the core AR System
environment:
BMC Remedy Distributed Server Option (DSO)Enables you to send and

receive data from forms that reside on physically separate servers. See
Distributed environments provide scalability on page 20 and the BMC Remedy
Distributed Server Option Guide.
BMC Remedy Encryption Security productsEnable the AR System server

and its clients to communicate securely over a network by encrypting the
messages sent between them.
BMC Remedy Encryption Standard Security is built into the BMC Remedy
products.
Optional BMC Remedy Encryption Performance Security and BMC Remedy

Encryption Premium Security are sold separately. The optional encryption
products provide a higher level of security than standard encryption. They
also enable you to comply with Federal Information Processing Standards
(FIPS) 200. All BMC Remedy Encryption Security products use third-party
encryption technology software developed by the OpenSSL Project for use in
the OpenSSL toolkit (http://www.openssl.org/).
See the BMC Remedy Encryption Security Guide.
BMC Remedy Full Text Search (FTS)Provides a search mechanism that is

typically much faster than the native database searching functionality for
searching in long text fields. It is also the only search method available in
AR System for searching text within documents attached to requests. See the
Configuration Guide, Using full text search, page 295.
BMC Remedy MigratorProvides a fast, easy way to move forms and

applications between AR System servers, servers and files, or files. This tool
helps you transfer data and workflow objects from a development environment
to a production server, while ensuring the integrity of all migrated changes. See
the BMC Remedy Migrator Guide.
NOTE
For limitations on using BMC Remedy Migrator with other BMC applications, see
the BMC Remedy Migrator Release Notes on the Customer Support website (http:/
/www.bmc.com/support).
60
Concepts Guide
BMC Atrium products
BMC Atrium products

Together, AR System and BMC Atrium Core provide the foundation for BMC
Business Service Management (BSM) solutions.
The following AR Systembased BMC Atrium Core components address the best
practices for configuration management. They also support IT Infrastructure
Library (ITIL)defined processes, such as change and service management.
BMC Atrium Configuration Management Database
BMC Atrium Integration Engine
BMC Product Catalog
The following BMC Atrium applications, though not based on AR System,

provide powerful visualization, decision support, and data discovery capabilities.
They are pre-integrated with BMC solutions for BSM and ready to use out of
the box.
BMC Analytics for BSM
BMC Dashboards for BSM
BMC Discovery Solution
For more information, see the BMC Software website at http://www.bmc.com.
AR Systembased solutions
The following BMC Remedy solutions for IT service and customer relationship
management are based on AR System:
BMC Remedy IT Service Management (ITSM) SuiteOffers a complete,

integrated solution to technology life cycle management. Its applications
compress business cycles with custom routing of approvals and consistent
enforcement of business rules. The suite includes
BMC Remedy Asset Management
BMC Remedy Change Management
BMC Remedy Service Desk (includes BMC Remedy Incident Management

and BMC Remedy Problem Management)
BMC Service Level Management
BMC Service Request ManagementEnables IT to define its services, publish

them in a Service Catalog, and give users self-service options, which reduce the
requests that must be handled by service desk support staff.
BMC Remedy Knowledge ManagementGives call center support staff easy

access to a vast array of information needed to resolve problems.
For more information, see the BMC Software website at http://www.bmc.com.
Chapter 5
Extending AR System
61
Other BMC products

Many other BMC productssuch as BMC Atrium Orchestrator, BMC Service
Impact Manager, and BMC Performance Managerintegrate with AR System or
applications based on AR System. Together, these products provide a complete
solution to Business Service Management (BSM).
For more information about BSM from BMC, see the BMC Software website at
http://www.bmc.com.
Integration with third-party products

AR System is designed to be used with third-party products to create an integrated
solution. Popular areas in which third parties have integrated their products with
AR System are
Web services
Network and system management
Computer telephony, including automated call distribution (ACD) and

integrated voice response (IVR)
Asset/inventory management
Groupware
Legacy management
Report writers
Remote access
Fax/pager/email
Knowledge bases
Accessibility for disabled AR System users
AR System is an open system with several well-defined interfaces for linking to

other products. For an in-depth discussion about integrating with third-party
products, see the Integration Guide.
For the latest information about products that have been integrated with
AR System, see the Customer Support website (http://www.bmc.com/support).
62
Concepts Guide
Chapter
An example BMC Remedy

AR System application
This chapter brings together the basic concepts of AR System by showing how a
sample organizationa wild animal parkmight plan and design an AR System
application. Like any business, the park needs to take a systematic approach to
automating its processes. This chapter walks you through the planning process
that the hypothetical park staff uses to evaluate and address its business needs.
About the wild animal park (page 64)

Goals of the animal tracking application (page 64)
Considerations (page 65)
Putting the example application to work (page 69)
Chapter 6 An example BMC Remedy AR System application
63
About the wild animal park

For many years, the wild animal park grew successfully with paper-based record
keeping combined with isolated computer-based procedures. Recently, however,
employees noticed a number of redundant or inefficient processes, so the park staff
decided to use AR System to automate the following processes:
Tracking and managing animals associated with the park
Tracking and managing public relations, such as attendance statistics, public

inquiries, membership renewals, and group tour information
Tracking and managing the maintenance of on-site visitor facilities, including

snack bars, restrooms, first-aid stations, and park transit systems
Managing the botanical gardens adjacent to the park
This chapter focuses on the first application, managing and tracking animals.
Goals of the animal tracking application

The park needs to accomplish these goals with the animal tracking application:
Track the type and number of animals grouped together in enclosures.
Track births, deaths, acquisitions, trades, and sales.
Track daily observations of each animal, including behavior and medical

condition.
Track the complete medical history of each animal, including preventive care
such as dental work, vaccinations, and parasite checks.
Track animal feeding.
Immediately alert the veterinary staff about medical emergencies.
Alert the animal handlers if any animal escapes its enclosure.
All these goals relate to tracking animals throughout their life at the park, as shown
in Figure 6-1 on page 65.
64
Concepts Guide
Considerations
Figure 6-1: Animal tracking overview
Considerations
After defining the application goals, the staff begins more detailed planning. This
section discusses various questions that any organization needs to consider to
create a useful application, including data analysis, workflow analysis, identifying
the business rules to be enforced, mapping the business rules to workflow
components, and considering whether any integrations are required.
NOTE
The planning and design process is thoroughly covered in the BMC Remedy
AR System 7.x: Application Requirements Analysis, Design, and Development
course offered by BMC. See http://www.bmc.com/education.
65
Analyzing data
As the park staff members begin to plan their animal management application,
they analyze the data by answering these questions:
What types of data do they need to capture?
How is this data stored in their current system (for example, in a legacy database
or in paper forms)?
What forms (main and supporting) and fields need to be created?
Should they include menus on the forms and, if so, which kinds are most
appropriate to help staff members fill in fields?
The staff determines that they need these forms (shown in Figure 6-2) to capture
information:
66
Animal formContains detailed information about each animal. The staff

considers using panel fields to organize the form modularly, keeping related
fields together.
Species Info formContains details about a particular species, such as feeding

requirements, life span, medical needs, and whether it is endangered. This is a
supporting form.
Feeding formContains information about each animals feeding schedule.
Enclosure formContains information about the number and types of animals

each enclosure can hold and so forth.
Medical History formContains the complete medical history of each animal.
Former Resident formContains information about animals that no longer

reside in the park.
Concepts Guide
Considerations
Figure 6-2: Forms for animal tracking application
Analyzing workflow
Next, the staff considers the parks current organizational processes:
What are the processes?
What are the stages or steps of each process?
Which groups of people participate in the processes?
To manage, access, and track the processes, what information do the groups
need?
Some of the AR System groups or roles that the park needs are:
Veterinarians, who provide health care for the animals.
Animal handlers, who provide day-to-day care for the animals.
Curators, who handle acquisitions and transfers.
Horticulturists, who maintain the animals naturalistic habitats.
Researchers, who conduct animal-related studies.
Appropriate permissions will be assigned to each group or role according to the

information that they need to access.
67
Defining business rules

After examining their business processes, the staff members also consider their
business rules, the fundamental policies that govern day-to-day life at the park. The
rules frequently provide the basis for making important decisions.
For example, one of the rules might be that every animal must be checked by a
veterinarian within 24 hours of arrival. If the rule is broken, that might indicate a
need to hire more medical staff or to increase clinic capacity.
Questions about business rules include:
What conditions and events require decisions and actions?
What should happen when various conditions or events occur?
What is the flow of information through the existing systems?
Business rules for the park include:
Animals will be not be kept in temporary enclosures longer than 48 hours.
Specially trained animal handlers will be notified immediately if a dangerous

animal escapes.
Every animal must be checked by a veterinarian within 24 hours of arrival.
Mapping business rules to workflow components

Next, the park determines how to translate its business workflow (rules and
processes) into AR System workflow components:
Which processes can be accomplished by using active links?
When would it make more sense to use a filter?
What types of escalations are needed to enforce business rules?
Some of the workflow components that the park needs are:
68
A filter to notify animal handlers whenever an animal needs to be moved.
Active links that help users fill out forms.
An escalation to enforce the rule that animals must be checked by a veterinarian

within 24 hours of arrival.
An escalation to notify keepers when an animal has not been fed within one
hour of its scheduled feeding time.
Concepts Guide
Putting the example application to work
Considering integrations
The staff considers what other software products or databases must initially be
integrated into the application and what future integrations are desirable:
The staff must be able to enter data while they are out in the park, perhaps using
handheld devices.
Future integration with a sister zoo must be possible.
Integration with an international database of endangered species is also

necessary, partly to locate new individual animals that can contribute to the
gene pool at the park.
Eventually, the staff might want to integrate information about the botanical
gardens at the park, although this could be maintained separately.

After the planning and design process, the park develops an application that
covers its diverse requirements. When staff members begin using the application,
they note which features work well and which ones need adjustment. Developers
make changes to the application based on that feedback.
Example applicationA tiger is acquired

This section describes an example in which the hypothetical wild animal park
acquires a tiger. This scenario illustrates a complete process, but not every
component of the process is discussed in detail.
As shown in Figure 6-3 on page 70, when a Sumatran tiger named Karuna is
obtained, a staffer fills in the Animal form, and then clicks a button called List
Enclosures. An active link opens a dialog box displaying the Enclosure form with
a table field that lists enclosure information, including availability and habitat. The
staffer can double-click any enclosure in the list to get more information.
Next, the staffer selects an appropriate choicein this case, enclosure 16and
submits the request. A filter notifies the Animal Handlers group and sends a
message to inform the staffer that the appropriate persons have been notified. In
addition, the Status field changes from New to Move Pending.
During trial runs of the system, the application developer realizes that the animal
handlers are frequently away from their computers and rarely check email. The
developer integrates the application with a paging program and has the filter
notify the handlers about new animals with a page. Handlers can then use their cell
phones to get information about their assigned tasks.
Gary from Animal Handlers receives a page that says a new tiger must be moved
from the temporary cages to enclosure 16.
69
After he transfers the tiger, Gary changes the Status field from Move Pending to
Permanent. When he saves his changes, workflow components create new
requests in related forms and notify the Veterinarian group and the Animal
Handlers group to begin the care and feeding of the new animal. These requests
and notifications illustrate one way of handling work orders in AR System.
Figure 6-3: Active link and filter in the animal tracking application
1
Dialog Box
Enclosure Form
Animal Form
Number
Name
Karuna
Type
Sumatran Tiger
Status
New
Active Link
lists all enclosures
and their capacity.
List
Enclosures
16
Assigned to
Enclosure
Status
Habitat
Full
Waterhole
Full
Steppe
16
Available
Jungle
20
Available
Steppe
Cancel
Continue
User submits
request.
User chooses Enclosure 16,

clicks Continue, and "16" is
entered.
Filter
Action 1.
Notify Animal Handlers group via email:
"New Sumatran tiger must be transferred
to Enclosure 16."
Action 2.
Notify Submitter: "Animal handlers have
been informed of tigers arrival."
TIP
This example is similar to moves, adds, and changes (MAC) in an employee services
application.
Example applicationThe tiger is injured

This section describes an example in which the tiger at the hypothetical wild
animal park is injured. This scenario illustrates a complete process, but not every
component of the process is discussed in detail.
70
Concepts Guide
One morning when the keepers are making their daily rounds, they notice that the
tiger, Karuna, has been injured, so they notify the veterinarians. A veterinarian
looks at the Animal form and checks a table field that contains data from the
Medical History form, as illustrated in Figure 6-4 on page 71. She discovers that
Karuna has no history of serious injury or illness.
To be treated, Karuna must be tranquilized and moved to the veterinary hospital
for surgery. He has been tranquilized before without incident as indicated by the
Tranquilizer Notes field on the Animal form, so the veterinarian computes the
dosage and sets out with several animal handlers to bring in the tiger.
Figure 6-4: Table field in the animal tracking application
During the prototyping phase, staffers had to open the Medical History form
separately to learn about Karunas record with tranquilizers. The veterinary staff
pointed out that they wanted that important information readily available during
an emergency. So the Tranquilizer Notes field was added to the Animal form, and
a filter that executes on Submit was added to post a message to the veterinarians,
reminding them to update the Tranquilizer Notes if necessary.
TIP
This process is similar to handling a customer call in a technical support
application. The technical support representatives might decide that they need
important information about a customer on a main form rather than on a
supporting form.
Example applicationThe tiger is traded to another zoo

This section describes an example in which the tiger, named Karuna, at the
hypothetical wild animal park is transferred to a different zoo. This scenario
illustrates a complete process, but not every component of the process is discussed
in detail.
71
After several years, the animal park determines that it should have a different male
tiger to maintain genetic diversity in its tiger population. By examining a database
maintained by zoos worldwide, the staff discovers a tiger that is available and has
no common ancestors with Karuna or with the parks female tigers. They decide to
trade Karuna, and a staffer changes Karunas status from Permanent to Trade
Pending, thereby triggering the same notification filter that was used when
Karuna arrived. This time, it notifies the animal handlers to move Karuna to a
temporary cage, as shown in Figure 6-5 on page 72.
Figure 6-5: Notifications in the animal tracking application
After Karuna leaves the park, his status is changed to Traded. When the changed
request is submitted, a filter uses a Push Fields action to move all of Karunas data
from the Animal form to the Former Resident form, as shown in Figure 6-6.
72
Concepts Guide
Figure 6-6: Push Fields action used in the animal tracking application
The Medical History form is not archived or changed because the staff might, at
any point, want information from the medical records. For example, they might
want information about all tiger surgeries performed at the park.
TIP
This process is similar to retiring an asset in an asset management application: you
need to track the problem history of an asset during its active use and after its
retirement.
73
74
Concepts Guide
Glossary
This glossary defines common terms used with
AR System.
access control
An AR System security feature used to limit

the access that users have to forms, to specific
fields or records in a form, to workflow, and to
specific functions in the system. See also
group, permission, role, user.
access point
A form or guide in an application that is used

as an interface to other applications or
workflow, such as in Push Fields or Call
Guide actions. When creating workflow that
references forms and guides, a developer can
identify access points.
action date
The duration within which an approver must

take action on a pending request. This value is
derived from various process intervals
defined on the AP:Process Definition form.
active link
A workflow component that causes an

AR System client to perform specific
operations in response to specific user actions.
Active links are generally employed to help
users interact with the system. They run on
the client computer or on the mid tier.
active link guide
An ordered sequence of active links that

accomplishes a specific operation. Active link
guides can lead users through a task (like a
wizard) or can be used as subroutines to
accomplish common tasks. See also filter guide.
Ad Hoc process
An approval process type with no predictable

routing, in which the requester and approvers
select the subsequent approver. See also
Parent-Child, Level, and Rule-Based process
types.
Ad hoc override
In Parent-Child, Level, and Rule-Based

processes, ad hoc overrides approvers to alter
the predetermined routing. The Allow Ad
Hoc Next Approver? field controls whether
the process allows this.
administrator
An individual responsible for the

management of AR System, including
installing AR System software and
maintaining AR System by adding and
deleting users, groups, and roles; backing up
AR System servers; importing data from other
systems; and so on.
administrator default
The value that AR System developers assign

to a field when designing a form. Users can
override the administrator default by
assigning their own default or by entering a
different value. See also user default.
Administrator group
One of several special access control groups

that AR System provides. Members of this
group have full and unlimited access to
AR System, including unlimited ability to
create definitions and to access and modify
data. See also explicit group, Sub Administrator
group.
Glossary
75
advanced search bar
The row of buttons, the Search Criteria field,

and the Fields menu list that appear at the
bottom of the Details pane when users click
the Advanced search button in a browser or
the View > Advanced Search Bar menu in
BMC Remedy User. Use this bar to specify
complex search criteria.
alert
A message from an AR System server or other

program to notify a user that certain events
such as a request being submitted or progress
being made in resolving a requesthave
occurred. You can use BMC Remedy Alert, an
optional Windows program, to notify users
when they receive alerts
alert list
The list of alerts belonging to a user. The list

can be displayed in a browser or in
BMC Remedy User.
allowable currency type
A currency type that appears in the currency

field menu. Users can use only allowable
currency types when entering currency
values. See also currency data type, functional
currency type.
alternate approve
An indication for notifications when an

alternate has responded with an approval.
alternate approver
An AR System user with the authority to

substitute for an approver within an approval
process.
alternate reject

alternate has responded by rejecting a request.
ancestor group
In a hierarchical group relationship, a parent

group or the parent group of a parent group.
See also child group, dynamic permissions
inheritance, hierarchical groups, parent group,
and static permissions inheritance.
API
See application programming interface (API).
76
Concepts Guide
application
A group of forms and associated workflow

related to a business function, such as
Employee Care or Service Desk. An
application is a server object in BMC Remedy
Developer Studio. See also deployable
application, local application.
Application Dispatcher
An AR System server process (Windows) or

daemon (UNIX) installed with the AR System
server that monitors the Application Pending
form, and signals other server applications,
such as the approval server, when they have
work to do.
application list field
A field that displays entry points. See also

entry point, entry point guide, form entry point,
home page.
application programming interface (API)
A set of functions or classes that provides

application programmers with access to the
full functionality of a product. The AR System
C API is documented in the C API Reference,
and the Java API is documented in the Java
API HTML documentation.
application state
The development state of a deployable

application, such as Test or Production. Roles
can be mapped to different groups based on
application state to limit access to the
application during testing or modification.
See also deployable application, group, role.
approval
An electronic signature by an authorized

person. In the approval server, an approval is
indicated by the status Approved on a
request that has followed an automated
process to gather the required signatures.
approval application
An interrelated set of forms, workflow,

processes and rules that allow users to enter a
request and approvers to respond, route the
request to completion, and generate
notifications related to the request.
Glossary
Approval Audit Trail
A field in the detail form that tracks all status

changes to the approval request, including the
date, time, and approver name.
approval process
A procedure that generates all necessary

signatures to authorize an approval request in
an AR System application.
Approval Process Done
A rule type used to update the request when

the approval process is done. These rules are
used to indicate the result of the approval
process to the original request.
approval request
A request entered in an approval application

to request authorization for a change, an
expenditure, or any other business situation
that requires signatures.
approval request form
An AR System form used by requesters to

enter a request for approval.
approved
The status of a signature when the approver

has authorized the request. Also, the status of
a completed approval request when all
approvers have authorized the request.
approver
An AR System user with the authority to

approve or reject approval requests.
approver list
The list of approvers eligible to respond on the

signature lines for an approval process.
AR System
See BMC Remedy Action Request System

(AR System).
AR System client
The AR System programs that enable users to

access an AR System server. AR System
clients include BMC Remedy Developer
Studio, BMC Remedy User, the web client
(mid tier), BMC Remedy Data Import, and
BMC Remedy Alert.
AR System database connectivity (ARDBC)
A mechanism by which the AR System server

uses a plug-in to access data stored outside the
AR System database as if it were in
AR System.
AR System external authentication (AREA)
A mechanism by which the AR System server

can access and use authentication services
from outside the AR System environment. A
plug-in is used to access the external
subsystem.
AR System ODBC driver
A connectivity solution that enables

AR System to communicate with ODBC
(Open Database Connectivity) clients. ODBC
is an SQL-based communication standard
developed by Microsoft.
AR System server
The AR System program that processes all

data entered by a client. The AR System server
is the workflow engine between client and
database. It also verifies that a user has
permission to perform each action, thereby
enforcing any access control defined in an
application.
ARDBC
See AR System database connectivity (ARDBC).

AREA
See AR System external authentication (AREA).

Assignee group

that AR System provides. The user whose
name is in the Assigned To field of a request
automatically belongs to this implicit group
for that request. See also Assignee Group group,
dynamic group, implicit group, Submitter group.
Assignee Group group

that AR System provides. If the Assignee
Group field in a request contains a user name,
that user is automatically a member of this
group for that request. If the Assignee Group
field contains a group name, all users in that
group are automatically members of the
group. See also Assignee group, dynamic group,
implicit group, Submitter group.
Glossary
77
attachment data type
The data type used for fields that hold files.

This type enables you to store text, graphics,
audio, or video attachments in the database.
attachment pool field
A field that contains one or multiple related

attachment fields associated with a request.
Auto Approval
A rule type that allows for automatic approval

by the approval server of a request that meets
specified criteria.
Base Development mode
A mode in BMC Remedy Developer Studio

that provides unrestricted access to create,
modify, and delete AR System origin objects,
such as out-of-the-box application objects.
This mode is intended to be used only by
AR System application developers. You
cannot create overlay or custom objects in this
mode, though you can modify and delete
them. See also Best Practice Customization mode,
overlaid object, origin object, overlay object.
Best Practice Customization mode
The default mode of BMC Remedy Developer

Studio. This mode enables you to indirectly
modify objects created in Base Development
modeincluding all out-of-the-box
AR System application and server objectsby
creating overlays for them and modifying the
overlays. Doing this ensures that your
modifications follow BMC development best
practices and that they will not be lost when
your application or server is upgraded. In this
mode, you can also create, modify, and delete
custom objects. You cannot create, directly
modify, or delete origin objects. See also Base
Development mode, overlaid object, overlay object.
BMC Remedy Action Request System (AR System)
Adaptable client/server software that

provides a foundation for creating
applications that can automate, track, and
manage a wide variety of business processes.
BMC Remedy Alert
The AR System client through which an alert

can be sent to a user. See also notification.
78
Concepts Guide
BMC Remedy Approval Server
An AR System application server that runs as

a plug-in. It routes an applications approval
request form to generate signatures. It collects
all the responses generated, and reports the
result of the approval process to the
application. The approval server also creates
an audit trail for all approval activity on
AR System application forms.
The AR System client tool used to transfer

data records from an archive file into a form.
BMC Remedy Developer Studio
The AR System client used by AR System

developers to develop applications. Use this
client to create and change object definitions
and to set access permissions that determine
which users and groups can view or modify
each form or specific parts of a form.
BMC Remedy Email Engine
A server-based module provided with

AR System that communicates with both the
AR System server and an email server. Email
Engine receives email messages and can parse
and interpret the messages to execute specific
instructions on an AR System form. It also
sends email messages to AR System and
directs notifications as a result of filters and
escalations.
BMC Remedy Flashboards
A real-time visual monitoring tool that can

show the state of service operations, warn
about potential problems, and collect and
display trend data.
BMC Remedy Mid Tier Configuration Tool
The tool used to configure and manage the

mid tier portion of AR System. See also mid
tier.
BMC Remedy User
The AR System client in which users enter and

track requests through the resolution process.
Users can also search the database, generate
reports, and modify existing requests.
(Alternatively, the mid tier enables you to
perform these tasks in a browser. See mid tier.)
Glossary
broadcast distributed transfer
A distributed operation in which one source

server simultaneously or consecutively
transfers data-only copies of requests to
multiple target servers. See also Distributed
Server Option (DSO).
button field
A field on a form that a user can click to

execute an active link. A button, image, or
hyperlink can represent a button field. See
also toolbar button.
cancel at later level

approval process is cancelled after it has been
approved by a previous approver.
cancelled
The status of a completed approval request

that was withdrawn by the requester or
cancelled by an approver or process
administrator.
chained approval process
A sequence of approval processes that appear

to the user as one approval, but in fact are
made up of two or more separate approval
processes.
chained distributed transfer
A distributed operation in which a request is

transferred from a source server to a target
server and then transferred from that target
server to another server. See also Distributed
change flag
A status flag set when the contents of a field or

form are altered. A change flag can be polled
or disabled by workflow.
character data type
The data type used for fields that contain

alphanumeric text.
character field
An AR System data field that holds

alphanumeric characters. You can attach a
menu or a file system browser to character
fields or fill them with default text.
character menu
A menu that provides assistance with filling

in values for a field. A character menu can be
attached to any character field. See also
dynamic menu.
child group
In a hierarchical group relationship, any

group that has a parent group defined. Where
allowed by the permissions inheritance
properties, this gives the parent group the
same access permissions to the object as the
child group. See also ancestor group, child
group, dynamic permissions inheritance,
hierarchical groups, parent group, and static
permissions inheritance.
client
See AR System client.

client tier
The architectural level in which AR System

clients operate in the multitiered system.
close approve
An indication for notifications when a request

has multiple possible but not required
approvers and another of the approvers
approves the request.
closed
The status of an approval request that has

been resolved and is no longer waiting for an
approver or More Information response.
close reject
An indication for notification when a request

has multiple possible approvers and another
of the approvers rejects the request.
command-line option
A parameter used to specify an operation or

option to AR System programs and utilities
when they are run.
Completion rule
A rule type that checks whether conditions

exist to stop routing a request. If a completion
check is successful, no new approvers will see
the request. The request might not be done,
but the request has been routed to everyone
who must respond.
Glossary
79
computed group
An explicit group whose membership is based

on the memberships of other explicit groups.
See also explicit group, group.
container
The underlying data structure for guides and

applications. A component of AR System
used to store collections of objects. Used as the
basic storage structure for applications, active
link guides, filter guides, and packing lists.
control data type
The data type for fields that execute active

links. These fields do not contain data.
control panel
A form used as a centralized entry point from

which users choose the business tasks they
want to accomplish.
core field
One of a set of basic fields common to all

AR System regular forms. These fields cannot
be removed from a regular form.
currency code
The three-letter code that represents a

currency type, such as USD for United States
dollars.
currency data type
The data type used for fields containing

currency data. Currency data is stored in four
parts: a decimal value, a currency code, a
conversion date, and one or more functional
(converted) currency values. Each part can be
viewed or searched by users or accessed by
workflow. See also allowable currency type,
functional currency type, currency code.
custom object
A standalone object created by users in the

Best Practice Customization mode of
BMC Remedy Developer Studio. (Objects
installed with AR System applications are
never custom objects; they are always origin
objects.) Custom objects are not modified or
lost during upgrades. See also Base
Development mode, Best Practice Customization
mode, origin object.
80
Concepts Guide
Customize group

that AR System provides. This group grants
users the right to customize their form layout
in BMC Remedy User. See also explicit group.
data field
A field that stores data in the database. Data

fields include character, date, time, date/time,
diary, integer, real, decimal, selection,
attachment, and currency.
data-only copy
In a distributed environment, a read-only

copy of a request that is not part of an active
ownership chain and cannot create a new
ownership chain. See also independent copy,
ownership chain, DSO server.
data tier
The architectural level that contains data and

communicates with the AR System server.
The data can be stored in a text file,
spreadsheet, or database that is part of or
separate from AR System.
data type
The property of a field that determines the

characteristics of the field and what type of
information (if any) the field can contain.
data visualization field
A field that provides a way to augment

AR System with HTML-based contentsuch
as web pages, flashboards, and other
graphicsthat can interact with the fields
parent form through workflow.
date data type
The data type used for fields containing date

values. Date values can range from January 1,
4713 B.C.E., to January 1, 9999 C.E. Date
values are stored as the number of days from
the beginning of the date fields range. For
example, January 1, 2009, is stored as the
number 2454833 because it is 2,454,833 days
after the first day in the date range. See also
date/time data type.
Glossary
date/time data type
The data type used for fields containing date/

time timestamp values. Values can range from
January 1, 1970, to January 17, 2038. See also
date data type, time data type.
decimal data type
The data type used for fields containing fixedpoint numbers.

default
See administrator default, user default.

default mapping
The mapping used by DSO when the DSO

action in a filter or escalation does not specify
a mapping. The Default Mapping field in the
Distributed Mapping editor is used to
designate default mappings. See also
Distributed Server Option (DSO).
deployable application
An application that uses permissions based on

roles and that is easily portable to other
servers. See also application, local application,
role.
detail record
The approval server creates an entry in the

AP:Detail form when a new approval request
is submitted. This form tracks the details of
the approval process for the request. It is part
of the two-way and three-way join forms that
are central to approval processing.
Details pane
The part of the main window in a browser or

in BMC Remedy User that displays fields for
entering or viewing data.
Developer Studio
See BMC Remedy Developer Studio.

dialog box
A window displayed to users that must be

responded to before users can continue filling
out a form. To create a dialog box, use an
active link action.
diary data type
The data type used for a field in which you can

capture a history of the actions taken for a
request. The field stores character data. It is an
append-only field, and each addition is
stamped with the time, date, and name of the
user who enters it.
display-only field
A temporary field for which no space is

allocated in the database. See also global field.
display-only form
A type of form containing display-only fields.

Display-only forms are used to create control
panels and dialog boxes.
distributed delete
A distributed operation that removes a copy

of a request from an AR System server. If the
master copy of a request is deleted, all copies
of the request in the associated ownership
chain are also deleted. See also Distributed
distributed fields
Fields that must be added to an AR System

form to enable DSO to perform ownership
transfers from and to the form. The three
groups of distributed fields (basic, full, and
advanced) provide different levels of control
over distributed operations. See also
distributed mappings
Objects on an AR System server that define

how data is transferred from one form to
another. Distributed mappings are used with
DSO filter and escalation actions. They are
created in the Distributed Mapping editor and
stored in the Distributed Mapping form. See
also Distributed Server Option (DSO).
distributed operations
Operations performed by DSO to manage

data transfers, updates, returns, and deletes in
a distributed environment. See also distributed
delete, distributed return, Distributed Server
Option (DSO), distributed transfer, distributed
update.
Glossary
81
distributed pools
Objects on an AR System server that enable

DSO to process multiple distributed
operations simultaneously and to ensure that
interrelated operations of pending distributed
items occur in the correct order. Distributed
pools are created in the Distributed Pool
editor and stored in the Distributed Pool form.
See also Distributed Server Option (DSO).
distributed return
A distributed operation that returns an

updated request with ownership to the
originating server. Distributed returns are
triggered by workflow on the server that
returns the request. See also Distributed Server
Option (DSO).
Distributed Server
The name of the internal AR System user that

performs all distributed operations for the
DSO server. See also DSO server.
Distributed Server Option (DSO)
An AR System server component that

transfers data among forms on physically
separate servers or on the same server. DSO
requires a separate usage license. See also
DSO server.
distributed transfer
A distributed operation that sends

information from a source form on one server
to a target form on another server or on the
same server. The transfer can include all or
some of the data in the request. See also
distributed update
A distributed operation that refreshes a copy

of a request when the master copy in an
ownership chain is modified. See also
done
An approval request is done when all the

required approvers have responded to the
request, or the request is cancelled, or the
approval server has put the request into an
error state.
DSO
See Distributed Server Option (DSO).

82
Concepts Guide
DSO actions
Actions configured in filters or escalations to

trigger distributed transfers, returns, and
deletes when specified criteria are met in a
form. See also distributed delete, distributed
return, Distributed Server Option (DSO),
distributed transfer.
DSO server
The arservdsd process (UNIX) and the
serverds.exe program (Windows) that
manage distributed operations. See also

duplicate request IDs
Matching request IDs that occur in a

distributed operation when a request
transferred from a source server has the same
request ID as a request on the target server.
DSO provides several ways to handle this
issue. See also request ID.
dynamic group

that developers can create in the Group form
by using a group ID from 6000060999. If a
dynamic group field (a field whose field ID is
the same as the dynamic group ID) contains a
user name, that user is a member of that
dynamic group. If the dynamic group field
contains a group name, all users in that group
are members of the dynamic group. If it
contains a role name, all members of the groups
mapped to that role are members of the
dynamic group. See also Assignee Group group,
group, implicit group, role.
dynamic menu
A menu populated at run time when users

click a search menu icon. The source of the
menu items is determined by values in other
fields on the form on which the menu appears.
See also search menu.
dynamic permissions inheritance
A form property that controls access to

requests by any ancestor group of a group
granted dynamic access to the request. See
also ancestor group, child group, hierarchical
groups, parent group, and static permissions
inheritance.
Glossary
email engine
See BMC Remedy Email Engine.

entry
See request.
entry point
A link on the home page that users click to

start a task (such as creating a request) or to
open a console (such as AR System
Administration Console). See also entry point
guide, form entry point, home page.
entry point guide
An entry point that starts a guide so that a user

can complete a task. See also entry point, form
entry point, home page.
error
The status of an incomplete approval request

in which routing problems have occurred.
escalation
A workflow component that searches at

specified times or intervals for requests
matching certain criteria and that performs
specified operations on the matching requests.
Escalations are generally used to find records
that have violated business rules or processes
and then to take the appropriate action. They
run on the AR System server. For example,
escalations for BMC Remedy Approval Server
requests are set relative to approval process
actions and states.
event
An occurrence in AR System that can trigger

other events or workflow. Examples include
user interactions with a form (such as opening
windows, tabbing from field to field,
switching row focus, and so on), state
transitions of requests, or any condition that
arises while a request is manipulated.
explicit group
A group to which users are assigned or that is

computed from other groups, such as
Administrator and Customize. See also
computed group, group, implicit group.
export
1. The BMC Remedy Developer Studio

command that writes definitions of objects
such as forms, filters, active links, and mail
templatesto a file. 2. To write object
definitions to a file by using BMC Remedy
Developer Studio or the export command-line
interface. 3. To write data entries to a file by
using the reporting feature in BMC Remedy
User. See also import.
field
The main component of an AR System form.

AR System field types include data, table,
panel, active link control (buttons, menu
items, and toolbar buttons), attachment pool,
view, and trim.
field ID
An integer that identifies a field throughout

AR System. Every field in a form must have a
field ID that is unique in that form. Field IDs
can be assigned manually by AR System
developers or automatically by AR System.
After a field ID is assigned, it cannot be
changed.
field label
A name that describes a fields purpose.

Intended to be displayed to users.
field name
A unique character identifier assigned to each

field. The name can be changed at any time as
long as the new name is unique.
file menu
A menu with items retrieved from a text file

containing a formatted character menu.
filter
A workflow component that tests every server

transaction for certain conditions and
responds to the conditions by taking specific
actions. Filters are generally used to check and
enforce business rules and processes. They
run on the AR System server.
filter API
An AR System plug-in API that enables

inline access during filter and escalation
processing to extended servers. See also
plug-in.
Glossary
83
filter guide
An ordered sequence of filters that

accomplishes a specific operation. Filter
guides can be used as a subroutine to
accomplish common tasks. See also active link
guide, filter.
fixed license
A license permanently assigned to a user,

enabling the user to access the licensed feature
at any time. See also floating license, write
license.
floating license
A license temporarily allocated to a user who

requests a license and who is designated as a
floating license user. If no floating license is
available at the time of the user request, the
user must wait until one becomes available.
See also fixed license, write license.
form
A collection of fields that represents a request

in AR System. AR System developers can
define and change the fields and workflow
associated with a form. An AR System
application can include many forms. In
AR System APIs, forms are called schemas. See
also request.
form action field
One of a set of special fields that perform

predefined operations in browsers for Webbased applications. The fields include Submit,
Query, Modify, and the Search Bar.
form entry point
An entry point that opens a form in a

particular mode, such as Search or New, so
that a user can complete a task. See also entry
point, entry point guide, home page.
form view
The screen layout for a form that appears in

the Details pane of a browser or BMC Remedy
User. AR System developers can create and
name multiple form views, which can be
further modified by users in the Customize
group. Developers can include or hide
different fields in various form views, and
they can create form views for particular
locales or user roles.
84
Concepts Guide
FTS
See full text search (FTS).

full text search (FTS)
A search mechanism that is typically much

faster than the native database searching
functionality for searching in long text fields.
It is also the only method available in
AR System for searching text within
documents attached to requests.
function
A named procedure that performs a distinct

operation in AR System. The AR System C
API has a set of functions used to accomplish
AR System tasks. Additionally, AR System
contains table functions that you can use in
workflow to perform mathematical
operations on table data.
functional currency type
An alternative currency type to which the

value in a currency field is converted. Values
for functional currencies are calculated
according to currency conversion ratios
maintained in a form on the server. Functional
currency values are stored as part of the data
in the currency field. Users can search for and
view them. Workflow can access them. See
also currency data type, allowable currency type.
Get Authority
A rule type that gathers information about the

current approver or environment that is used
by subsequent Self Approval or Completion
rules.
Get Authority Regular

by subsequent completion rule tests.
Get Authority Self

by subsequent Self Approval rule tests.
Get Next Approver
A rule type that finds the next approvers in

the current process, including the first
approver at the start of processing. Also, a
stage of the approval process.
Glossary
global field
A display-only field whose value is the same

across all forms that contain the field as long
as the user is logged in. See also window-scoped
global field.
group
A category in AR System used to define user

access to form fields and functions.
AR System defines several special groups:
Public, Administrator, Sub Administrator,
Customize, Submitter, Assignee, and
Assignee Group. You can define additional
groups through the Group form. See also
access control, explicit group, implicit group,
computed group, dynamic group, permission, role,
user.
Group form
The form in which you can create, modify, and

delete explicit groups and assign floating
licenses to them. See also explicit group, license.
guest user
Unregistered user with a limited set of

capabilities (can submit and possibly review
requests). An administrator can specify
whether unregistered users are allowed at
your site.
GUID field
A field that is automatically populated with a

globally unique identifier (GUID) when a
request is saved.
guide
See active link guide and filter guide.

hidden field
A field on a form that is not visible to a user.

hierarchical groups
Groups that are related by assigning the

Parent Group field in the Group form. The
hierarchy consists of a parent group and one
or more child groups. A child group can also
be a parent to another child group. See also
ancestor group, child group, dynamic permissions
inheritance, parent group, and static permissions
inheritance.
hold
An indication for notifications when a request

is changed to the Hold status. This is also a
status in which an approval request is
assigned to an approver but the approver has
held the request. In this case, no approval
server activity occurs until the hold is
removed.
home page
A form that lists entry points. The entry points

are displayed in an application list field. In
BMC Remedy User, the home page form can
be configured to open on user login by
default. In browsers, users enter or click a link
to a home page URL. See also entry point,
application list field, entry point guide, form entry
point.
image object
An image stored in the AR System database

along with information defining the image as
an AR System object. If you use the same
image in more than one location, such as the
background for a related set of forms, you
store the image once as an image object and
then include it by reference in form view and
field display properties.
implicit group
A group to which users are automatically

assigned according to the contents of certain
fields in a request, such as Submitter and
Assignee. See also dynamic group, explicit
group, group.
import
1. The BMC Remedy Developer Studio

command that transfers object definitions
from an export file to the current server. 2. The
BMC Remedy Data Import command that
transfers one or more data entries from an
archive file to a form. See also export.
independent copy
A modifiable copy of a distributed request

that is not part of an ownership chain.
Independent copies cannot receive updates
from the master copy, but they can start new
ownership chains. See also Distributed Server
Option (DSO), ownership chain.
Glossary
85
integer data type

numeric values from 2147483647 to
2147483647. The range for a field can be
limited by an AR System developer.
join form
A type of form that contains information from

two or more AR System forms. Although join
forms function similarly to regular forms, they
do not store data. A join form references data
stored in the forms used to create the join
form. For example, BMC Remedy Approval
Server uses the two-way join form AP:DetailSignature, and a three-way join form, which is
a join between the applications approval
request form and AP:Detail Signature.
keyword
A variable whose value is defined by

AR System. For example, $USER$ represents
the name of the user currently logged in.
Keywords can be used in qualifications for
searches, search menus, workflow, and
macros or to specify a value in the Set Fields
action for active links, filters, and escalations.
Level
An approval process type with relationships

based on the approvers membership in
organizational groups (not AR System
groups). See also Parent-Child, Ad Hoc process,
and Rule-Based.
license
See fixed license, floating license, read license,

restricted read license, write license.
local application
An application that uses permissions based on

groups and that is intended for use on a
limited number of servers. See also application,
deployable application, role.
macro
A set of operations in BMC Remedy User

recorded for later execution. Macros are
useful for automating frequently used or
complex operations.
86
Concepts Guide
macro bar
The row of buttons below the menu bar in

BMC Remedy User that provides easy access
to commonly used macro commands. Macro
commands are also available from the Tools
menu.
mail template
A template used to submit a request by email.

The export command can be used to generate
templates from an existing form.
main form
A form that users interact with directly. An

application can have more than one main
form. Main forms are sometimes called
primary forms or consoles.
main window
The BMC Remedy User window that displays

a form in the Details pane and, optionally, the
results of a search in the Results pane and
prompt text in the prompt bar. The main
window includes a menu bar and optional
status bar, toolbar, and macro bar.
mapping
See distributed mappings.

mapping history
Records stored in a forms Mapping History

distributed field. A mapping history record is
created each time that a distributed transfer
occurs. The record includes the date and time
of transfer, source request ID, source form,
source server, and mapping name. See also
master copy
The copy of a distributed request that has

ownership. See also Distributed Server Option
(DSO).
Master Flag
A basic distributed field that indicates

whether a distributed request is the master
(has ownership). See also Distributed Server
Option (DSO).
Glossary
mid tier
A component of AR System consisting of addin services that communicate between

AR System servers and various clients.
BMC Remedy User can communicate directly
with AR System servers. Browsers, however,
must use the mid tier to communicate with
AR System servers.
More Information request
An approvers query for additional data that

becomes part of the audit trail of the approval
request. The approver is not required to delay
the approval request until someone responds.
more info return
An indication for notifications when a More

Information request has been responded to.
navigation field
A field that enables users to navigate through

screens in an application quickly and easily.
new signature
An indication for notifications that a new

signature record has been created for an
approval request.
notification
A message to a user from workflow.

Notifications can be sent by various
mechanisms, including alerts and email. See
also alert, email engine. For example, in
BMC Remedy Approval Server, notifications
are linked to the approval request status and
process states.
object modification log
A feature of the AR System server that logs all

changes made to an object and that can save a
copy of an object in a definition (.def) file
each time that the object is changed.
object reservation
A feature of the AR System server and

BMC Remedy Developer Studio used to
prevent others from modifying objects that
are in use.
ODBC
See AR System ODBC driver.
operator
A function that is used to define advanced

searches or to build qualifications.
origin object
An object created in the Base Development

mode of BMC Remedy Developer Studio. All
out-of-the-box AR System application and
server objects are origin objects. Avoid
modifying origin objects because your
modifications might be lost during upgrades.
Instead, create an overlay for such objects and
modify the overlay. To add an object to
AR System, avoid creating an origin object
because it also might be lost during an
upgrade. Instead, create a custom object. See
also overlaid object, overlay object, unmodified
object.
overlaid object
An object for which an overlay exists. See also

origin object, overlay object, unmodified object.
overlay hash file
An XML file that contains keys and valid and

invalid hash values for all the objects in a
particular version of AR System or an
AR System application. Overlay hash files are
used by the Best Practice Conversion utility to
generate difference reports. Overlay hash files
are also known as snapshots.
overlay object
A copy of an AR System object that is used in

place of the origin object. Overlays are created
in the Base Development mode of
BMC Remedy Developer Studio. To ensure
that customizations are preserved during
upgrades, you modify the overlay, not the
origin object. During upgrades, the overlay is
ignored whether or not the upgrade program
modifies the origin object definition. After the
upgrade, AR System continues to use the
overlay in place of the origin object. See also
Best Practice Customization mode, origin object,
overlaid object, unmodified object.
override approve
An indication for notifications when a process

administrator has approved a request in a
manner that circumvents the normal process.
Glossary
87
override reject
An indication for notifications when a process

administrator has rejected a request in a
manner that circumvents the normal process.
ownership
In a distributed environment, the ability to

update a request in an ownership chain.
Ownership can be transferred from the
original request to a copy, and ownership can
be returned. See also Distributed Server Option
(DSO), independent copy, ownership chain.
ownership chain
A series of distributed requests representing a

history of transfers with ownership. See also
Distributed Server Option (DSO), independent
copy, mid tier.
packing list
A set of associated server objects that can be

viewed as a work space in the server window
or used in external utilities.
page field
See panel field.

panel field
A type of field that acts as a container in which

related fields can be grouped. A panel field
can stand alone or be managed by a panel
holder field. In previous releases, called a page
field. See also panel holder field.
panel holder field
A field that contains one or more panel fields.

Panel holders enable groups of fields to be
organized and displayed in the same area of a
form. They manage various panel layouts,
including tabbed, collapsible, splitter, and
accordion. See also panel field.
Parameterized Get Next Approver
A rule type that uses run-time variables to

find approvers in the current process. It lets
requesters and approvers add additional
approvers to any level in an approval process
(not just the next level).
Parent-Child
An approval process type with a fixed

relationship between approvers, such as a
management hierarchy. See also Level, Ad Hoc
process, and Rule-Based.
88
Concepts Guide
parent group
Any explicit group that has a defined

hierarchical relationship to another group (the
child group) through the Parent Group field
in the group form. Where allowed by the
permissions inheritance properties, the parent
group inherits the permissions assigned to the
child group for the object. See also ancestor
group, child group, dynamic permissions
inheritance, hierarchical groups, and static
permissions inheritance.
pending
The status of an incomplete approval request

awaiting response or more information from
an approver. Also, the status of a signature
line that is waiting for a response from the
approver.
pending distributed item
A distributed operation waiting to be

performed. Pending operations typically
occur because a specified transfer interval has
not been met or because network or server
problems exist in a distributed environment.
Pending distributed items are listed in the
Distributed Pending form. Failed pending
distributed items are listed in the Distributed
Pending Errors form. See also Distributed
permission
The property setting that controls who can

view and change individual fields on a form
and who can access certain types of objects,
including active links, active link guides, and
applications. See also access control, group, role,
user.
plug-in
An auxiliary program that works with the

AR System server to enhance its capabilities.
A plug-in is a dynamically linked library
(DLL) on Microsoft platforms, a shared library
on UNIX platforms, or a Java archive (JAR) on
all platforms. The plug-in server loads
plug-ins at run time. For example,
BMC Remedy Approval Server is a plug-in.
Glossary
plug-in server
A server that loads and executes plug-ins. The

plug-in server is a companion to the
AR System server. It loads the ARDBC,
AREA, or filter API plug-ins at run time.
pools
See distributed pools.

preference server
An AR System server that stores user

preferences centrally in the AR System User
Preference form.
Prep Get Next Approver
A rule type that gathers information to be

used by the Get Next Approver rules.
process administrator
An AR System user who is a member of the

Approval Admin group (402). Process
administrators can have authority to set up
and maintain approval processes, or to act as
an override approver only.
prompt bar
The part of the main window in BMC Remedy

User that displays instructions or useful
information about the form it is attached to.
Public group

that AR System provides. Every user is
automatically a member of this group.
qualification
A filter or search criterion including field

references, values, and arithmetical and
relational operators used to determine how to
process a request or to find a set of data. For
example, in BMC Remedy Approval Server
processes, rules, and workflow objects,
qualifications are used to determine whether
the process, rule, or filter should run, and to
control data gathering.
query-by-example (QBE)
A method for visually describing a database

search. An empty form is displayed, and the
search conditions are entered in their
respective fields. AR System turns the visual
query into the command language, such as
SQL, required to query the database.
read license
A license that allows users to search

AR System forms and to submit requests but
not to modify requests. See also restricted read
license, write license.
real data type

floating-point numbers. The range and
precision can be set by AR System developers.
reassign
An action for an approver to reroute a request

by changing the assigned approvers.
regular form
A form used to manipulate and display data.

Regular forms and their contents are stored in
database tables created, owned, and managed
by the AR System server.
reject by another approver
An indication for notifications when multiple

required approvals are outstanding and one
of the other approvers rejects the request.
reject by later level

approval process is rejected by an approver
after it has been approved by a previous
approver.
rejected
The status of a completed approval request

when an approver has rejected the request.
Also the status of the signature line of the
approver who has rejected the request.
request
A collection of information that describes

something, such as a user, a problem, or a
service. When a form is filled in and submitted
to AR System, the system creates a request. A
request is equivalent to a record in the
database. In AR System APIs, requests are
called entries. See also form.
requester
A user who submits a form to request an

approval, triggering approval server action.
request ID
A unique identifier generated by AR System

for each request. See also Request ID field.
Glossary
89
Request ID field
A core field on a form that contains the request

ID. In join form entries, the Request ID field
contains the request ID for each of the
underlying forms, separated by a vertical bar.
reserved field
A data field that has a predefined special

purpose in AR System. If you add a reserved
field to a form, the field retains its special
behavior and use.
restricted read license
A license that allows users to search

AR System forms and submit requests but
does not allow users to modify requests under
any condition. It does, however, allow the
same login to access AR System from multiple
computers simultaneously. See also read
license.
results list
A list of requests that match a search. Multiple

rows (or requests) in the results list that meet
specified criteria can be selected for further
processing.
Results pane
The part of the form window in a browser or

in BMC Remedy User that displays the results
of a search.
return
See distributed return.

role
In a deployable application, a configuration

that defines access to form fields and server
objects. Roles are defined in the Role Mapping
form and then mapped to groups on the
server on which the application is installed.
Different groups can be mapped to the same
role for each development state of the
application. See also access control, application
state, deployable application, group, permission,
Roles form, user.
role (approval server)
A named alias for one or more approvers.

Using roles allows the definition of a position
regardless of the individual approvers who
are currently fulfilling that position.
90
Concepts Guide
Roles form
The form in which roles are created and

mapped to groups for each application state.
See also application state, group, role.
Rule-Based
A custom approval process type designed by

the process administrator, in which
relationships are defined by rules rather than
by data in a form. See also Parent-Child, Level,
and Ad Hoc process.
schema
See form.
search
The process by which users display a subset of

requests according to search criteria that they
define.
search menu
A menu whose items are based on data

retrieved from a search of an AR System form.
See also dynamic menu.
Section 508
A law that requires U.S. federal agencies

electronic and information technology to be
accessible to people with disabilities (visual,
motor, and auditory impairments).
selection data type
The data type used for fields with a set of

mutually exclusive options. Multiple options
are displayed as option (radio) buttons or as a
list. A single option can be displayed as a
check box.
selection list
A list that appears when an active link

performs a search that returns more than one
request.
Self Approval
A rule type that allows for automatic approval

of a request if the submitter of the request has
sufficient authority for the request to be
approved.
server
See AR System server, BMC Remedy Approval

Server, DSO server, plug-in server, preference
server.
Glossary
server group
A group of AR System servers configured to

share the same database. See also AR System
server.
server tier
The architectural level consisting of the

AR System server that controls access to the
data and any supporting services called or
used by the AR System server.
signature
An entry in the AP:Signature form that

represents the response of an approver to an
approval request.
Signature Accumulator
A rule type that is used to collect statistical

information about the signature records
associated with an approval process.
signature authority
The ability of an approver to authorize a

request, based on policies established by the
organization and defined in a signature
authority form.
signature authority form
A form created by the administrator that

contains approver names or roles and their
signature authority limits, to support data
gathering by get authority rules.
signature record
A database record in the AP:Signature form

that represents the signature of an approver. If
an approval request requires more than one
signature, multiple signature records are
generated for that single approval request.
Simple Object Access Protocol (SOAP)
The primary transport protocol for messages

shared by applications in web services. SOAP
is an XML-based packaging format for the
transferred information. It contains a set of
rules for translating applications and
platform-specific data types into XML.
snapshot
See overlay hash file.
SQL menu
A menu whose items are based on data

retrieved from a direct SQL command to a
SQL database.
static permissions inheritance
An object property that controls whether the

ancestor groups of a group in the permission
list of the object are granted the same access to
the object as the group in the permission list.
See also ancestor group, child group, dynamic
permissions inheritance, hierarchical groups, and
parent group.
Statistical Override
A rule type that is used to preempt the default

behavior of the approval process and follow
an approve or reject path before all pending
signatures have been completed.
status bar
The part of a main window in an AR System

client that displays instructions or useful
information to the user.
Status field
The core field (ID 7) in which AR System

tracks the various stages of the resolution
process for a request. For example, in
BMC Remedy Approval Server, the AP:Detail
form uses this field to track the overall status
of the request. In the AP:Signature form, the
field is renamed to Approval Status, and it
tracks the approval status of the individual
signature line.
status history
A field that displays information about the

progress of a request.
Sub Administrator group

that AR System provides. Members of this
group have limited administrative access to
AR System as defined by an administrator.
See also Administrator group, explicit group.
subadministrator
A member of the Sub Administrator group.
Glossary
91
Submitter group

that AR System provides. The user whose
name is in the Submitter field on a request
automatically belongs to this implicit group
for that request. See also Assignee group,
Assignee Group group, implicit group.
supporting form
A form that supplies information needed by

another form. See also main form.
table field
A field that displays data from other requests

in the current request. A table field can appear
in a list view format (with rows and columns),
a tree view format, or a cell-based format.
See distributed transfer.

transfer mode
In a distributed environment, one of four

types of distributed transfers (data only,
data + ownership, independent copy,
copy + delete) that determine whether the
copy of the request is sent with ownership and
whether the original is deleted. See also
trim data type
The data type of fields that enhance a forms

usability and appearance. Trim includes lines,
boxes, text, and URL links. These fields do not
contain data.
unmodified object
task
A shortcut or link created in BMC Remedy

User that enables users to quickly open a
specific form, search, application, or active
link guide.
time data type
The data type used for fields containing time

values. Time values are stored as the number
of seconds from 12:00:00 a.m. See also date/
time data type.
toolbar
1. Standard: In BMC Remedy User, the row of

buttons below the menu bar that provides
easy access to commonly used menu
commands. In a browser, toolbar buttons
along the top of the form provide the
equivalent functionality of menus and
toolbars in BMC Remedy User. 2. Formspecific: A separate toolbar with additional
icons that can appear on certain forms.
toolbar button
An icon for a menu item that triggers an active

link. See also button field.
tooltip
A brief informational message displayed

when a user interacts with an objectsuch as
a table row, attachment, or field labelon the
screen. A tooltip is displayed by hovering the
mouse over an area on a form or by clicking an
object such as a button.
92
transfer
Concepts Guide
A customization type that describes an object

for which an overlay does not exist. See also
origin object, overlaid object, overlay object.
update
See distributed update.

user
Any person with permission to access

AR System. See also access control, group,
permission.
user default
A value for a field that a user can predefine. A

user default overrides an AR System
developer default in BMC Remedy User. See
also administrator default.
User form
The form in which users are added to

AR System and in which each users group
membership, login, and license information
are specified.
Validate Approver
A rule type that is used to verify that a name

specified as the next approver is a valid user.
Only used to verify a user specified in an Ad
Hoc process or an ad hoc override of another
process type.
variable
A data element that changes according to

conditions.
Glossary
vendor form
A form used to connect to external data

sourcessuch as text or spreadsheet data
residing on local or remote serversthrough
an ARDBC plug-in. See also AR System
database connectivity (ARDBC).
view
See form view.

view field
A field that provides a browser window in a

form. Can be used to display a URL, the
contents of an attachment, direct HTML text,
or content formatted by a template.
view form
workflow
1. A set of business processes used to run a

company. 2. The automation of business
processes through actions performed by
active links, filters, and escalations.
write license
A license that allows a user to modify and

save data in existing requests, subject to field
and form permission settings. See also fixed
license, floating license, read license, restricted
read license.
XML Schema or XML Schema Definition (XSD)
A means of defining the structure, content,

and semantics of XML documents.
A form used to connect to database tables not

created by AR System.
view user interface (VUI)
A structure that contains information about a

single form view.
web client
A browser communicating with the

AR System server through the mid tier.
web service
An object that enables messages to be sent to

and received from an application over a
network (Internet or intranet), using standard
Internet technologies. It uses a combination of
protocols such as HTTP and XML that are
platform independent.
Web Service Description Language (WSDL)
An XML-based language used to define web

services and how to access them.
wildcard
A character that represents other characters in

a search. For example, in search statements in
character and diary fields, users can specify
wildcards to match single characters, strings,
or characters in a range or set.
window-scoped global field
A display-only field whose value remains the

same across requests in the same window as
long as the window is open. See also global
field.
Glossary
93
94
Concepts Guide
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A
access control
about 49
groups, about 50
groups, membership 53
groups, types 52
hierarchical 54
licensing and 56
multitiered 54
permissions, additive 52
role-based 53
users and 50
actions
about workflow 40, 41
Change Field 41
Close Window 41
if/else 40, 45, 47
Message 42
Notify 42
Open Window 42
Push Fields 42
Run Process 42
Service 43
Set Fields 43
active links
about 23
API calls and 39
execution options 43
execution order 44
guides 40
user-controlled execution options 44
adaptability, AR System 13
additive permissions 52
Administrator access control group 52
administrators, responsibilities 25
AIE 17
Alert List form 16
alert list tables 32
alerts 16
analytics 61
animal tracking example application 63
Apache Tomcat 18
API calls, workflow and 39
application list fields 32
application programming interfaces. See API
applications
about 21, 35
animal tracking example 63
components 21
deployable 35
entry points 32
forms and 35
local 35
localizing 36
AR System database connectivity (ARDBC)
database servers and 19
architecture, AR System 14
ARDBC. See AR System database connectivity
asset management products 61
Assigned To field 33
Assignee access control group 52
Assignee Group access control group 52
attachment fields 32
B
BMC Analytics for BSM 61
BMC Atrium applications 61
BMC Atrium CMDB 61
BMC Atrium Core 61
BMC Atrium Integration Engine 17, 61
BMC Atrium Orchestrator 62
BMC Dashboards for BSM 61
BMC Discovery Solution 61
BMC Performance Manager 62
BMC Product Catalog 61
BMC Remedy Alert 16
BMC Remedy Asset Management 61
BMC Remedy Change Management 61
BMC Remedy Data Import 17
BMC Remedy Developer Studio 17
BMC Remedy Distributed Server Option 20, 60
Index
95
BMC Remedy Encryption Performance 60
BMC Remedy Encryption Premium 60
BMC Remedy Encryption products 60
BMC Remedy Incident Management 61
BMC Remedy IT Service Management Suite 61
BMC Remedy Knowledge Management 17, 61
BMC Remedy Mid Tier. See mid tier
BMC Remedy Migrator 17, 60
BMC Remedy Problem Management 61
BMC Remedy Service Desk 61
BMC Remedy User 16
BMC Service Impact Manager 62
BMC Service Level Management 61
BMC Service Request Management 61
BMC Software, contacting 2
browsers, AR System user interface 16
BSM 12, 61, 62
Business Service Management 12, 61, 62
button fields 32
Button/Menu Field execution option 43
C
cell-based tables 32
Change Field action 41
change management products 61
character menus 34
client tier, AR System 14
client-based workflow 39
clients
AR System 16
architectural tier 14
BMC Atrium Integration Engine 17
BMC Remedy Alert 16
BMC Remedy Data Import 17
BMC Remedy Developer Studio 17
BMC Remedy Knowledge Management 17
BMC Remedy Migrator 17
BMC Remedy User 16
browser-based 16
developer 17
integration 17
user 16
Windows-based 16
Close Window action 41
CMDB 61
components
application 21
example of how they work 24
workflow 38
computed groups 52
configuration management database 61
96
Concepts Guide
consoles, applications and 35

control fields 32
control panels 29
core AR System 59
core fields 33
Create Date field 33
custom access control groups 52
custom objects
definition 23
custom objects, about 23
customer support 3
customizations, preserving 23
Customize access control group 52
D
dashboards 61
data
fields 28
importing 17
tier, AR System 14
working with external 19
data dictionary menus 35
data fields 32
data forms 29
data visualization fields 32
database servers 19
databases
forms in 29
platforms for AR System 19
deployable applications 35
developer clients 17
Developer Studio 17
developers, responsibilities of AR System 26
dialog boxes 29
discovery products 61
display-only fields 32
display-only forms 29
distributed computing environments 20
Distributed Server Option 20, 60
documentation, AR System 7
DSO. See Distributed Server Option
dynamic groups 52
E
else actions 40, 45, 47
encryption
performance 60
premium 60
standard 60
engines
engines (continued)
JavaServer Pages 18
JSP 18
servlet 18
entry points 32
environments, computing
distributed 20
heterogeneous 20
mixed 20
escalations
about 23
events, triggering workflow with 39
examples
animal tracking application 63
application components at work 24
AR System adaptability 13
service desk solution 12
execution options
about workflow 38, 40, 43
active link 43
Button/Menu Field 43
escalation 45
event-triggered 39
filter 43
Gain Focus 43
Hover 43
Lose Focus 43
Menu Choice 43
Modify 44
Service 44
Submit 44
Table Refresh 44
time-triggered 39
user-controlled 39, 44
Window Open 44
execution order
active link 44
filter 44
explicit access control groups 52
extending AR System 59
external data, working with 19
F
Federal Information Processing Standards (FIPS) 60
fields
about 28
application list 32
attachment 32
button 32
character 34
fields (continued)
common characteristics 33
control 32
core 33
data 28, 32
data visualization 32
database table columns and 29
display-only 32
label styles 34
menu items 32
navigation 32
panel 32
table 32
toolbar buttons 32
trim 32
types 32
view 32
file menus 34
filters
about 23
API calls and 39
execution order 44
guides 40
FIPS 60
Fixed licenses 57
Floating licenses 57
forms
about 21, 28
Alert List 16
applications and 35
consoles 35
data 29
database tables and 29
display-only 29
fields 28
home pages 32
join 29
main 35
menus 22
primary 35
regular 29
supporting 35
types 29
vendor 29
view 19, 29
views 21, 30
foundation products, AR System 60
FTS 60
Full Text Search 60
Index
97
G
Gain Focus execution option 43
groups
access control 50
computed 52
dynamic 52
explicit 52
implicit 52
local applications and 35
membership in access control 53
regular 52
server 18
guides
active link 40
filter 40
Last Modified By field 33

licenses
access control and 56
Fixed 57
Floating 57
pools 57
Read 56
Restricted Read 56
list view tables 32
local applications 35
locale 36
localizing applications 36
Lose Focus execution option 43
if actions 40, 45, 47

implicit access control groups 52
importing data 17
incident management products 61
Information Technology Infrastructure Library 12
integrating with other products 17, 59
ITIL 12
ITSM 61
main forms 35
membership, access control group 53
Menu Choice execution option 43
menu item fields 32
menus
about 22, 34
character 34
data dictionary 35
file 34
search 34
SQL 35
Message action 42
mid tier
about 18
AR System architecture and 14
Migrator 17
mixed computing environments 20
Modified Date field 33
Modify execution option 44
multitiered access control 54
JavaServer Pages engines 18

join forms 29
JSP engines 18
navigation fields 32
navigation, consoles and 35
Notify action 42
keywords 47
knowledge management products 17, 61
objects
See also custom objects, origin objects, overlaid
objects, overlays
Open Window action 42
OpenSSL Project 60
operating systems, AR System server 18
H
help desk products 61
heterogeneous computing environments 20
hierarchical access control 54
home pages 32
horizontal navigation fields 32
Hover execution options 43
L
label styles, field 34
98
Concepts Guide
origin objects
definition 23
overlay objects. See overlays
overlays
definition 23
overlays, about 23
P
panel fields 32
performance encryption 60
permissions. See access control
pools, license 57
predefined access control groups 52
premium encryption 60
primary forms 35
problem management products 61
Product Catalog 61
product support 3
Public access control group 52
Push Fields action 42
Q
qualifications 46
query-by-example (QBE) searches 19
R
Read licenses 56
records 21, 29
regular forms 29
regular groups 52
Request ID field 33
requests
about 21
creating 29
database table rows and 29
Restricted Read licenses 56
results list tables 32
roles
access control and 53
deployable applications and 35
Run Process action 42
S
search menus 34
searches
about 19
FTS 60
searches (continued)
query-by-example (QBE) 19
server tier 14
server-based workflow 39
servers
AR System 18
database 19
database platforms 19
groups 18
operating systems for AR System 18
Service action 43
service desks
example solution 12
products 61
Service execution option 44
service level management products 61
service request management products 61
servlet engines 18
Set Fields action 43
Short Description field 33
SLM 61
solutions 61
SQL menus 35
SRM 61
Standard BMC Remedy Encryption 60
Status field 33
Status History field 33
Sub Administrator access control group 52
Submit execution option 44
Submitter access control group 52
Submitter field 33
support, customer 3
supporting forms 35
T
table fields 32
Table Refresh execution option 44
tables, database 29
technical support 3
third-party products and AR System 62
tiers, AR System architecture 14
time, triggering workflow by 39
toolbar button fields 32
tree view tables 32
trim fields 32
U
user clients 16
user interfaces, AR System
browser 16
Index
99
user interfaces, AR System (continued)
Windows 16
users
controlling execution options 44
users, access control and 50
V
variables, keyword 47
vendor forms 29
vertical navigation fields 32
view fields 32
view forms 19, 29
views, form 21, 30
W
Window Open execution option 44
Windows, AR System user interface 16
workflow
See also actions, execution options
about 22, 37
actions 40, 41
AR System and 38
client-based 39
components compared 22, 38
event-triggered 39
execution options 38, 40, 43
guides 40
server-based 39
time-triggered 39
100
Concepts Guide
*183974*
*183974*
*183974*
*183974*
*183974*

BMC Remedy Action Request System 7.6.04 Concepts Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BMC Remedy Action Request System 7.6.04 Concepts Guide

Transféré par

Droits d'auteur :

Formats disponibles

BMC Remedy Action Request System 7.6.

Contacting BMC Software

United States and Canada

BMC SOFTWARE INC

713 918 8800 or

(01) 713 918 8000

713 918 8000

Outside United States and Canada

(01) 713 918 8800

Copyright 19912011 BMC Software, Inc.

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

Operating system and environment information

Sequence of events leading to the problem

Commands and options that you used

Product error messages

License key and password information

E-mail customer_support@bmc.com. (In the Subject line, enter SupID:yourSupportContractID, such

Submit a new issue at http://www.bmc.com/support.

About BMC Remedy Action Request System

Forms and applications

About AR System forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Workflow in general and in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Types of workflow components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

About access control in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

AR System foundation products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

An example BMC Remedy AR System application

About the wild animal park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Overview of AR System architecture and features; includes Everyone

Instructions for installing AR System.

BMC Remedy Action Request System 7.6.04

Information about the development of AR System

Workflow Objects Guide

Information about the AR System workflow objects (active Developers

Information about configuring AR System servers and

Information about monitoring and maintaining AR System Administrators/

Database administration topics and rules related to how

BMC Remedy Distributed

Information about implementing a distributed AR System

BMC Remedy Flashboards

Instructions for creating, modifying, and administering

Information about AR System data structures, C API

C API Quick Reference

Quick reference to C API function calls.

Java Plug-in API

Information about Java classes, methods, and variables used Programmers

BMC Remedy Email Engine

Instructions for configuring and using BMC Remedy Email Administrators

Error Messages Guide

Descriptions of AR System error messages.

Combined index of all books.

BMC Remedy Approval

Instructions for using BMC Remedy Approval Server to

Information about new features, compatibility, and

Release Notes with Known

Information about new features, compatibility, international Everyone

BMC Remedy User Help

Instructions for using BMC Remedy User.

BMC Remedy Developer

Instructions for using BMC Remedy Developer Studio to

BMC Remedy Data Import

Instructions for using BMC Remedy Data Import.

BMC Remedy Alert Help