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

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

Form to review the responses to a request

The AP:Signature form stores the signature lines for approval requests. Administrators can use this form to review the responses to a request. However, you should modify this information only through Approval Central.

AP:Signature form

(Click the image to expand it.)


Fields on the AP:Signature form

Field

Description

Approval ID

The BMC Remedy AR System populates this field with the AR System ID for this request.

Approvers

The BMC Remedy AR System populates this field with the name of the approver for this signature line.

Note: A maximum of 4000 characters are allowed in this field. The characters are truncated if this limit exceeds.

More Information

The BMC Remedy AR System populates this field with the questions and answers to More Information Requests.

Approval Status

The BMC Remedy AR System populates this field with the status of the request. For more information about Approval Status, see Checking status of requests and Working with Approval Status and More Information requests.

Next Approver

The BMC Remedy AR System populates this field in an ad hoc situation with the name of the next approver.

If Multiple Approvers

This field is valid only if multiple entries exist in the Next Approver field. Select one of the options:

  • One Must Sign — A single signature entry is created for all approvers in the Next Approver field. Only one of those approvers needs to take action on the request.
  • All Must Sign — Separate signature entries are created for all approvers in the Next Approver field. All approvers must act on the request for it to move to the next stage.

Alternate Signature

The BMC Remedy AR System populates this field with the user name of an alternate approver, if the alternate acts on the request.

Approver Signature

The BMC Remedy AR System populates this field with the user name of the approver when the approver acts on the request.

Signature Method

The BMC Remedy AR System populates this field with the method by which this request was approved.

  • Alternate — An alternate signed this request instead of a normally scheduled approver.
  • Regular — A normally scheduled approver signed this request.
  • Override — Someone with process administration authority performed an override to respond to this request instead of a normally scheduled approver.

Assignee Group Permissions

The Remedy AR System populates this field with the Assignee Group for the request. This field supports the multi-tenancy feature.

Full Name

Used to store the full names of approvers to whom the corresponding request is assigned.

Role ID

Used to make a signature role aware. For more information, see Creating signature escalations.

The approval server automatically drops duplicate signature lines if an approver appears in multiple groups to which a request is assigned or if there are duplicate individual mappings.
In such an event, entries such as the following are recorded in the approval log:

<APPR> * Process option set to not validate user so no work needed
<APPR> Expanding roles for approver(s): SGP000000000082|CAB-Member
<APPR> Expanding roles for approver(s): SGP000000000084|CAB-Member
APPR> Dropping duplicate approver line for USER1;USER2;USER3;
<APPR> Dropping duplicate approver line for USER1;USER2;USER3;

You can safely ignore such log entries. The signature lines are dropped because the approval server maintains only one signature line for an approver per request until the associated process is active.

Full Name

The approval server uses the login name to search for the corresponding full name when creating a signature entry. It first searches the User forms, and if they do not full name information is not present, it searches the custom form specified on the AP:Process Definition form. This information is stored in the Full Name character field (14201). See Full name form.

If there is no custom Full Name Form, or if the full name information is not found through this form, the login name is used as default.

Setting the full name on a signature line is a one-time activity; this value is not set at run time. The full name provided at the time of signature line creation stays constant. When upgrading to release 7.5.00 or later, if the Full Name value is not available, it is set according to the current Full Name value from the related form. If the Full Name value must be set dynamically, application developers must write the appropriate escalations. Applications can fetch user information from different forms, such as the User form, the CTM:People form, and so on.

Role ID

If a signature is created by expanding a role, the Role ID character field (14200) stores the role ID of the source role, which was expanded to create the individual signature line. The following situations could occur:

  • If a role has One Must Sign set to true, only one signature entry is created for all the members belonging to the role. The related role ID is copied to the Role ID character field.
  • If a role has All Must Sign set to true, the role ID is copied to each signature entry that is created by expanding the role.

Depending on the process definition, the signature entries are created as follows:

  • When One Must Sign is defined at the process level, only one signature entry is created, regardless of the If Multiple Approvers setting at the role level. In this case, the individuals defined as approvers and the individuals expanded from the roles provided as approvers appear in a single signature entry. Role IDs for all the roles in the approvers list are put in the newly added field on the AP:Signature form for the corresponding signature.
  • When All Must Sign is defined at the process level, multiple signatures are created according to the If Multiple Approvers setting at the role level. In this case, each signature entry contains the role ID that was responsible for creating the entry by expanding the individuals in the role.

The values in the Role ID field could differ as follows:

  • The Role ID field remains blank for individuals in the approvers list.
  • The Role ID field can have a single role ID or multiple roles IDs based on the definitions. All role IDs are enclosed between semicolons.
  • Consider a case where a role is defined as an approver, which in turn is composed of roles. When this is expanded recursively to write individuals in the signature entry, the Role ID field has the role ID of the base role that was provided as the approver.
    For example: The Finance role contains the users Jim and Frank. The Purchase role contains the users Paul and Bob. The Administrator role is a superset of Finance, Purchase, and a few more roles. When the Administrator role is defined as an approver for a request, even though it expands the Finance, Purchase, and other roles recursively to get individual approvers, the Role ID fields of the signatures created for these approvers contains the role ID of the Administrator role.

Related topic

Working with If Multiple Approvers field

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

Comments