This documentation supports the 18.05 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.



You can continue to use C APIs to customize your application, but C APIs are not enhanced to support new capabilities provided by Java APIs and REST APIs.


Creates a new escalation with the indicated name on the specified server. The escalation condition is checked regularly based on the time structure defined when it is enabled.


BMC Remedy AR System administrator.


#include "ar.h"
#include "arerrno.h"
#include "arextern.h"
#include "arstruct.h"

int ARCreateEscalation(
ARControlStruct *control,
ARNameType name,
AREscalationTmStruct *escalationTm,
ARWorkflowConnectStruct *schemaList,
unsigned int enable,
ARQualifierStruct *query,
ARFilterActionList *actionList,
ARFilterActionList *elseList,
char *helpText,
ARAccessNameType owner,
char *changeDiary,
ARPropList *objPropList,
char *objectModificationLogLabel,
char *taskName,
ARStatusList *status)

Input arguments


The control record for the operation. It contains information about the user requesting the operation, where that operation is to be performed, and which session is used to perform it. The user and server fields are required.

If a valid overlay group is specified in the control record, the ARCreate* function creates a custom object that belongs to that group. If no group is specified, the function creates an origin object. To specify an overlay group, use the AR_SESS_CONTROL_PROP_DESIGN_OVERLAYGROUP variable of the ARSetSessionConfiguration function (see ARGetSessionConfiguration).


The name of the escalation to create. The names of all escalations on a given server must be unique.


The time specification for evaluating the escalation condition. This parameter can take one of two forms: a time interval that defines how frequently the server checks the escalation condition (in seconds) or a bitmask that defines a particular day (by month or week) and time (hour and minute) for the server to check the condition.


The list of form names the escalation is linked to. The escalation must be associated with a single form or a list of forms that currently exists on the server.


A flag to enable or disable this escalation. A value of 0 disables the escalation, causing its condition checks and associated actions to not be performed. A value of 1 enables the escalation, causing its conditions to be checked at the specified time interval.


A query operation performed when the escalation is executed that determines the set of entries to which the escalation actions (defined by the actionList parameter) are applied. Specify NULL or assign an operation value of 0 (AR_COND_OP_NONE) to match all schema entries.


The set of actions performed for each entry that matches the criteria defined by the query parameter. You can specify from 1 to 25 actions in this list (limited by AR_MAX_ACTIONS).


The set of actions performed if no entries match the criteria defined by the query parameter. These actions are not performed for all non-matching entries. You can specify from 0 to 25 actions in this list (limited by AR_MAX_ACTIONS). Specify NULL for this parameter (or zero actions) if you do not want to define any else actions.


The help text associated with the escalation. This text can be of any length. Specify NULL for this parameter if you do not want to associate help text with this object.


The owner for the escalation. The owner defaults to the user performing the operation if you specify NULL for this parameter.


The initial change diary associated with the escalation. This text can be of any length. The server adds the user making the change and a time stamp when it saves the change diary. Specify NULL for this parameter if you do not want to associate change diary text with this object.


A list of server object properties. If this parameter is set to NULL, a properties list with zero properties is associated with the escalation, and a list of zero properties is returned when an ARGetEscalation is performed. See Server object properties.


The version control label that the API function must apply to the object. If the label name does not exist on the server, the function creates it.

Ripple actions

Rename and Delete operations typically change multiple objects in addition to their primary target object. The Rename or Delete function must apply the version control label to all the objects that it affects.

Multiple API calls for a single user action 

Some user actions trigger a sequence of API calls. In that situation, the last API call in the sequence applies the version control label to the object. Thus, clients that create forms (like BMC Remedy Developer Studio does) should provide the label only to the last call. For example, when a form is created, a client might issue these calls:

  • ARCreateSchema
  • ARCreateMultipleFields
  • ARSetVUI
  • ARSetVUI
  • ARSetSchema

In this case, the objectModificationLogLabel value should be passed only to the last call, ARSetSchema, even though the user provides the label during the ARCreateSchema operation.

Operations on label-related forms

Version control labels cannot be applied to these forms:

  • AR System Version Control: Label
  • AR System Version Control: Labeled Object
  • AR System Version Control: Object Modification Log

Return values


A list of zero or more notes, warnings, or errors generated from a call to this function. For a description of all possible values, see Error checking.

See also

ARDeleteEscalation, ARGetEscalation, ARGetListEscalation, ARSetEscalation. See FreeAR for: FreeARFilterActionList, FreeARQualifierStruct, FreeARStatusList, FreeARWorkflowConnectStruct, FreeARPropList.

Was this page helpful? Yes No Submitting... Thank you