This documentation supports the 20.02 version of Remedy Action Request (AR) System.

To view an earlier version, select the version from the Product version menu.


Form to create and modify approval processes

The AP:Process Definition form opens when you click View or Create on the Process tab of the AP:Administration form. Process administrators use this form to create and modify approval processes. See Using the Process tab on AP-Administration.

You can also open this form using Quick Links > Approval Administration Console.

Basic tab

AP:Process Definition form — Basic tab
(Click the image to expand it.)


Fields on the AP:Process Definition form — Basic tab

FieldDescription
ProcessEnter a name for this process. Process names must be unique and must have no more than 254 characters (including spaces). It is helpful to make the name descriptive of the process's function.
FormSelect the AR System form that you are connecting to the approval server. This becomes the approval request form.

Note: You must add the form to the Form tab of the AP:Administration form to make it appear on this menu.
Type

Select the process type from the available options:

  • Parent-Child
  • Level
  • Ad Hoc
  • Rule-Based

See  Approval process types.

Status

Select the process status from the available options:

  • Active — (Default) The process generates approvals for the approval request form.
  • Inactive — The process is disabled and generates no approvals.

You might want to set the status to Inactive during the development of the process and the associated rules. When all the appropriate rules are in place, you can modify the process and set the status to Active. Requests related to processes in the Inactive state are displayed on Approval Central, but approvers cannot act upon such requests. The following message is displayed in such an event:
This action is not allowed on the selected requests, because the related process is inactive. (ARERR 46411). However, approvers can take action on requests that are related to processes in the Inactive state from the application's three-way join. To prevent approvers from acting on such requests from the three-way join, developers need to write the appropriate workflow.

Request Owner FieldEnter a valid AR System user name or select the field that identifies the owner of the approval request from the menu. The fields in this menu are populated from the approval request form.
First Approver FieldEnter a valid AR System user name or select the field that identifies the first approver for this process from the menu. The fields in this menu are populated from the approval request form. This field is required for Ad Hoc process type, optional if you allow ad hoc overrides, and otherwise unused.
Generate Preview

Select generate preview setting from the available options:

  • None — The approval server does not generate preview information in the Preview Signatures form for the process.
  • On Request Only — The approval server generates preview information only when it receives a Generate-Preview signal. With this option, the application controls the load on the approval server.
  • On Start of Process— The approval server generates preview information when any of the following events occurs:
    • A Generate-Preview signal is received.
    • A new approval process starts (for example, when a details request is created, or when an existing request that was closed is reopened).
    • A new signature is created.
    • The status of an existing signature changes.
  • On Generation or Change to a Signature— The approval server generates preview information when any of the following events occurs:
    • A Generate-Preview signal is received.
    • A new approval process starts (for example, when a details request is created, or when an existing request that was closed is reopened).
    • A new signature is created or the status of an existing signature is changed.
  • Real-time Only — The approval server generates preview information (but does not cache it) only when a preview is requested. This option displays the most current information, but it puts the highest load on the approval server.

Note: If you select the On Request Only, On Start of Process, or On Generation or Change to a Signature option, the preview displayed might not be the most current information.

Can Reassign?Specify whether approvers should or should not be able to reassign a request of this process type to another approver.
Full Name FormSelect a form that provides the full name of the approver to be added to the signature line. You could also enter a custom form name by using the adjacent text field. This information is pushed to the Full Name field on the AP:Signature form.
Exclude User Field

This menu lists all the fields on the application form. Select a field that contains Login Names. The users from the selected field are excluded from the list of approvers (their signatures are not created) for a request of this process type. If the selected field contains a role:

  • Users belonging to that role are excluded.
  • If the role is part of an approval chain and contains only one user, the other approvers can act on the request and the process can complete successfully regardless of the One Must Sign or All Must Sign setting. If an excluded user is an approver in the middle of an approval chain, the approver before the excluded user can act on the request, and the request remains open. However, when the excluded user is encountered, the request state is changed to Error on the application and detail form, and no further action can be taken. The exclusion takes place only after the Get Next Approver rule is executed. Because these users are excluded from the list of approvers, they do not appear on the Approver tab of the AP:Show-Detail form. For a Level process, if one of the approvers is excluded on a level, other approvers can take action, and the request can proceed. When processing Auto Approval and Self Approval rules, the approval server ignores this field. If a user specified in this field is the only approver for the request, the approval process fails and an error is reported. The user exclusion operations and the related errors, if any, are listed in the approval log files. The values in this field are ignored in the following situations:
  • When defining a process:
    • If you select the Ad Hoc type.
    • If one of the users specified for exclusion is also specified as the first approver.
  • When acting on a request (regardless of process type):
    • If an approver reassigns a request to one of the users specified for exclusion.
    • If an approver specifies one of the users specified for exclusion as the next approver.

      Note: The check for excluding users from the list of approvers is done before signature creation, therefore it does not impact the requests for which signatures have already been created.
Approval Success

Select the manner with which the approval server determines whether the approval process for a request is complete:

  • No More Approvers — (Default) The process is complete when all signature lines are complete. If you select this option and if the signature line for a request is cancelled and no other signature exists, the request is marked Approved, not Cancelled.
  • Completion Rule — Use a Completion rule to determine the successful completion of the approval process. If you select this option, you must create a Completion rule and associate it with this process or the process is never considered complete.
If Multiple Approvers

This field applies only if you are defining an Ad Hoc process or are going to allow ad hoc overrides. The value you select determines how many signature line records the approval server creates when building an approver list. Specify using the available options how to manage signature entries when a request is assigned to multiple approvers:

  • One Must Sign — Create only one signature line for a list of potential approvers. The signature line is complete when one of the approvers acts on the request. The first approver to act on the request determines the response; the request is withdrawn from the other approvers.

    Note: The field for approver names on a signature-line record is limited to 255 characters on certain databases. Using roles might help you to work around this limitation, because roles are internally expanded to individual approver names during further processing.
    This option overrides the If Multiple Approver setting on any roles selected as an approver.

  • All Must Sign — Create separate signature lines for each approver. All approvers must act on their own signature line for the request to proceed.

If an approver list includes roles, the If Multiple Approver setting for the specific role determines whether the role is expanded into individual signature lines for each member of the role or a single signature line is created for the entire role. See Defining roles.

  • Allow Only One Approver — (Default) Create a single signature line for one individual. If you use this option and a requester specifies multiple approvers, the approval server stops the process and marks it as an error.

For information about how notifications are sent when a request is approved or rejected, see Form to create and modify notifications sent by approval processes.

Allow Ad Hoc Next Approver?

This field applies to Parent-Child, Level, and Rule-Based process types. Specify using the available option whether users can add approvers to the approver list for a request:

  • Anyone — The requester and any approver can select an ad hoc next approver.
  • Approver — Only approvers can specify an ad hoc next approver.
  • No one — (Default) The process should not allow users to specify an ad hoc next approver.
For Self Assignment

This field specifies how the approval server determines the next approver, when the requester is not the person who submitted the approval request (for example, when an assistant enters an approval request on behalf of someone else). Select from the available options:

  • Use Get Next Approver Rules — (Default) Use a Get Next Approver rule to determine the first approver.
  • Assign to Owner if Approver — Use the requester as the first approver if the requester is defined as a valid approver for the approval server. If you select this option, you must define a Validate Approver rule to verify whether the owner is a valid approver.
  • Always Assign to Owner — Use the requestor as the first approver in all cases.
Validate Approvers?

This field tells the approval server whether to verify the value in your next approver field with a Validate Approver rule when creating a request. Select from the available options:

  • Yes — Validate the approvers when saving a request.
  • No — (Default) Skip validating approvers.

Require Password?

This field determines whether the approver must enter a password to save changes to an approval request. Select from the available options:

  • Yes — Mandate the use of a password when saving changes to an approval request.
  • No — (Default) Allow saving changes to request without validating the password.
Assignee Group PermissionsThe BMC Remedy AR System populates this field with the Assignee Group for the request; the Public group is selected by default. The approval server uses this field to support multi-tenancy for use by application service providers. If you use this field for multi-tenancy support, create workflow to populate this field with the correct assignee group name. You do not need to change this setting when creating the rule. The ID of this field is 112, and it appears on all approval server forms. The field 112 value from records created in the AP:Detail form is used automatically in all the other approval server forms (for example, AP:Signature, AP:More Information, and so on). See Error 333 and Assignee Group Permission.
Ad Hoc Settings

This field is enabled only if you select:

  • An Ad Hoc process type
  • A process type other than Ad Hoc and "Anyone" or "Approver" in the Allow Ad Hoc Next Approver field The options are:
  • Default — (Default) Disables the adjacent Ad Hoc Form field. When an approver clicks the Adhoc button on the AP:Show-Detail form, the AP:AdhocDialog dialog box appears. Data about the ad hoc approver entered through AP:AdhocDialog is stored in the AP:AdhocDetails form.
  • User Defined — Enables the adjacent Ad Hoc Form field. When an approver clicks the Adhoc button on the AP:Show-Detail form, the form specified in the Ad Hoc Form field appears. Data about the ad hoc approver entered through this form is stored in the AP:AdhocDetails form.
Ad Hoc FormThis drop-down list displays all the forms in the AR System server. Select the form that you want to be displayed when an approver clicks the Adhoc button on the AP:Show-Detail form. Approvers should be able to provide data about ad hoc approvers in this form, and the form should have the necessary workflow to store this data in the AP:AdhocDetails form. If you select a custom form, make sure that application developers have added the necessary fields and workflow to it.
Retrieving first approver failed, error?

This field determines the course of action in case the approval server fails to retrieve the first approver for a request.

  • Yes — (Default) Set the state of the request to Error and add the error details to the audit trail.
  • No — Set the state of the request to Pending. Later, if Add-Sig is started for that request, the same AP:Detail record is used.
SearchAppears in the Search mode; click to search the AP:Process Definition form.
SaveAppears in the New mode; click to save the entry to the AP:Process Definition form.
CloseCloses the window without saving.

Request Owner field

The setting of this field is crucial for:

  • The execution of Self Approval rules — The value of this field is compared with the current user's name, and if they match, the rule is executed, otherwise it is skipped.
  • Finding the first approval in the approval chain — In the Parent-Child, Level, and Rule-Based process types, the first approver in the chain is completely dependent on the name of the person stored in the field mapped to AP:Process Definition > Request Owner Field. The Request Owner field must contain a valid entry in the approval lookup form (for example, AP-Sample:Signature Authority is the lookup form for the Lunch Scheduler sample application). To set an appropriate value for Request Owner field, a process administrator must consider the following:
    • Does this field store the name of the person defined in the approval lookup form?
    • Is the organizational structure for this user defined in the approval lookup form? The value of Request Owner field is not considered when finding the first approver in an ad hoc process, because the requester is responsible for specifying all the required approvers.

Full name form

If your application does not contain a User form that contains the full name of a person, you should create a custom form that provides this information. The custom form should contain the following character fields, with their input lengths set to 0:

  • The field with the ID 10001 contains the login name.
  • The field with the ID 10002 captures the full name, which can be generated by any means.

Create a filter on this form, which runs on a service action. This filter uses the data in the first field (10001) as input to generate the corresponding full name for the second field (10002).

Configuration tab

AP:Process Definition form — Configuration tab
(Click the image to expand it.)


Fields on AP:Process Definition — Configuration tab

FieldDescription

Process Intervals

These fields are used to determine the action date for signatures on a request pertaining to this process. See Associating an action date for a process or signature.

Process DueEnter a number in the Interval field and the select the Unit of measurement. This specifies the total duration in which the process is due.
Signature DueEnter a number in the Interval field and the select the Unit of measurement. This specifies the total duration in which each signature for the process is due.

Note: If you enter a value more than what is specified in Process Due, this value is ignored. The value in Process Due is then used to compute the action date, instead of the one you specify in this field.
Buffer PeriodEnter a number in the Interval field and the select the Unit of measurement. This buffer period is considered as a delta to be deducted from all process intervals, except Signature Due, when computing the action date.
Enable PreviewSelect Yes to use the Preview feature in calculating the Signature Due Date. The Preview feature is used to fetch information about the future approvers, to calculate the total number of signatures required to complete the process. The Signature Due interval is then computed as the Process Due interval divided by the total number of signatures required. Select No to avoid the use of the Preview feature. In this case, only the value specified in Signature Due is considered.

Note: This field is used only in the case of Parent-Child and Level processes. The value of this field is not considered when calculating the Signature Due interval for ad hoc requests.
Specify menu name to list users for the following operations
More Information Reassign Ad-hocSelect the menu from which to derive user names for the corresponding operations. The selected menu determines the list of users that appears when a user creates a More Information request (by adding a question or comment), or chooses to reassign a request, or to assign a request to an ad hoc approver. If you do not specify a menu for any of these operations, users do not have the option of choosing names from a user list; they can continue with the operation by entering login names manually.
Rejection Justification
Require Justification on RejectionSelect Yes to make it mandatory for an approver to provide a justification when rejecting a request. In addition to storing the justification in various approval server fields, it is pushed to the application form's field specified in the Justification Field menu. Select No to indicate that rejection justification is optional; an approver is not prompted to justify rejecting a request. However, if provided, the justification is processed further.
Justification Field

Select the field in which to store the rejection justification. This menu lists Character fields from the application form.

Note: Currently, this menu also displays Attachment fields along with Character fields, because of an AR System server issue.

From the list of available fields, select a Character field whose length is unrestricted (0 ). Otherwise, if the approver enters a justification of more than 255 characters:* A warning is added to the approval log.

  • The justification is not made available on the application form.

If you do not select a field from this menu, the approver's input is stored in the Justification field (ID 14518) on AP:Signature and as a comment of the Justification type on AP:Question-Comment-Info. See Form to provide justification for rejecting approval requests.

Signature Escalations tabs

AP:Process Definition form — Signature Escalations (Normal) tab
 (Click the image to expand it.)


The three tabs (Normal, Urgent, and Low) on the Signature Escalation tab contain identical fields.

Fields on the AP:Process Definition form — Signature Escalations tabs

FieldDescription
Use schedules
Business calendarUse the drop-down list to select a workday schedule created on one of the business time workday forms.
Holiday calendarUse the drop-down list to select a holiday schedule created on one of the business time holiday forms.
Automatic action
After IntervalType a numeric value for the amount of time to pass before this action is taken. For example, type a 2 for two hours or two days. The unit is determined in the next field.

Note: This is called the Automatic Action interval, which is used to compute the action date for the corresponding process.
UnitSelect the unit of Hours or Days as the unit for the interval in the previous field.
Change StateUse the drop-down list to select the status you want to force on this request if no activity occurs in the interval defined in the two preceding fields. Leave this field and the preceding two empty if you do not want the status of a request changed automatically.

Note: This reflects on AP:Show-Detail > Action Date field and Approval Central > Action Date column. See AP-Show-Detail form and Approval Central.
Notifications (Notification: Still Outstanding and Notification: Still in State) are used to determine the escalation or notification mechanism for signatures on a request.

Notification: Still Outstanding Use these fields to send a notification to an approver whose signature is in Pending or Hold state for a specified interval.

First IntervalType a numeric value for the amount of time to pass before this notification first occurs.

Note: This is one of the Escalation intervals, which is used to compute the action date for the corresponding process.
UnitSelect the unit of Hours or Days for the interval in the previous field.

Note: This reflects on Approval Central > Past Due requests > Action Date column. See Approval Central.
Repeat IntervalType a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.
UnitSelect the unit of Hours or Days for the interval in the previous field.
Notification: Still in State
Use these fields to send a notification to an approver for signatures in an active state.
On StateSet the separate escalation and repeat intervals to occur when a form is saved with the status of Pending, Error, Hold, or More Information.
First IntervalType a numeric value for the amount of time to pass before this notification first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.

Note: This is one of the Escalation intervals, which is used to compute the action date for the corresponding process.
UnitSelect the unit of Hours or Days for the interval in the previous field.
Repeat IntervalType a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.
UnitSelect the unit of Hours or Days for the interval in the previous field.

More Information Escalations tab

You can use the fields on this tab to send a notification to the addressee of the More Information request.

AP:Process Definition form — More Information Escalations tab
 (Click the image to expand it.)


Fields on the AP:Process Definition form — More Information Escalations tab 

FieldDescription
Use schedules
Business calendarUse the drop-down list to select a workday schedule created on one of the business time workday forms.
Holiday calendarUse the drop-down list to select a holiday schedule created on one of the business time holiday forms.
Notification: still outstanding
First intervalType a numeric value for the amount of time to pass before this action first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.
UnitSelect the unit of Hours or Days for the interval in the previous field.
Repeat intervalType a numeric value for the amount of time to pass before this action recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.
UnitSelect the unit of Hours or Days for the interval in the previous field.

Administrative info tab

For more information about the Administrative Information tab, see Administrative Information tab.

Related topic

Working with If Multiple Approvers field

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

Comments