Skip to content
CA Service Management - 14.1
Documentation powered by DocOps

Use Policies to Manage Requests

Last update October 7, 2014

This article contains the following topics:

CA Service Catalog administrators can create policies. Policies define conditions for automatically designating specific users as the assignees for a task during the request life cycle. The most common use is to define conditions for automatically assigning specific approvers for services and service options in a request pending action.

Policies provide the flexibility to assign tasks (such as approval or rejection of requests pending action) to users other than the managers of the requestor. However, you can optionally include these managers in your list of assignees.

The policy that you create consists of the following main components:

  • The condition under which the policy applies
  • The assignment to occur if the condition is met.
    If the condition is met, the user or users you specify are assigned to perform a pending action.
    You can specify the list of assignees according to any of several attributes, including but not limited to:
    • User name (first name and last name)
    • Membership in a user group
    • Management hierarchy, meaning the manager of the user, the manager of that manager
  • An active-or-inactive setting
  • Description and priority fields

You create global policies and global actions for general use with any service. In contrast, you create attached policies and actions for use with a specific service option only. You can create an attached policy or action only from the Policies & Actions tab of that service option.

Comparison to Events, Rules, and Actions

The conditions and actions that you specify in policies are similar to the rules and actions that CA Service Catalog supplies in events. You can view and edit these events, rules, and actions by selecting Administration, Tools.

In both the cases, you specify conditions that become part of the request life cycle workflow in CA Service Catalog. In both cases, when a request meets the specified conditions, CA Service Catalog assigns the users that are specified in the policy. For example, suppose you create a policy that applies only to requests with cost greater than $100. When a user submits a request that meets this condition, the assignees that are specified in the policy are assigned a pending action to approve, reject, or fulfill the request.

The major difference is that events, rules, and actions are system wide. But, you can optionally specify policies to be either system wide or specific to a business unit.

Step 1 - Review the Criteria to Apply Policies to Individual Requests

CA Service Catalog matches policies to individual requests according to priority and business unit (tenant) level in the following order. 

  1. High-priority policies at the lowest level business unit (farthest from the root)
  2. High-priority policies at the next lowest level business unit
  3. High-priority policies at the remaining business unit levels, from the lowest though the highest (the root)
  4. Low-priority policies at the lowest level business unit
  5. Low-priority policies at the next lowest level business unit
  6. Low-priority policies at the remaining business unit levels, from the lowest though the highest
  7. When CA Service Catalog matches a policy to a request, it considers other policies only if they are at the same priority and business unit level.
  8. If CA Service Catalog finds two or more policies at the same priority and business unit level, it assigns requests pending action to all applicable assignees from all applicable policies.

The Catalog system requires all approvals from these assignees to advance the request pending action to the next status in the request life cycle. To help avoid situations in which multiple policies and approvers apply to a single request pending action, create and maintain conditions to use specific criteria.

Step 2 - Create Folders for Policies

You can create and maintain folders (as needed) to store your policies. Organize  policies in folders according to the business units and child business units to which they apply, using intuitive names. Similarly, suppose that the policies apply to all business units. In that case, you can organize them according to categories under a folder that is named For All Business Units.

Follow these steps:

  1. Click Catalog, Policies.

  2. Add a folder, as follows:
    1. Select the folder to which you want to add the new folder and click Add, Folder.
      For example, to add a folder to the root folder (the Policies folder), select it and click Add Folder.
    2. Enter the name of the new folder and click OK.

      The folder is created and appears under the parent folder.

You can create, rename, move, copy, and delete folders.

Note: The names of folders are case-aware, but not case-sensitive. Thus, when you rename a folder, change more than the case. For example, you cannot rename an existing folder from spg policies to Spg Policies or SPG POLICIES.

Step 3 - Enable Rules and Actions for Policies

Policies require an engine. The rules and actions that you enable depend on the engine you use. On the Details Tab for any service that wants to associate with a policy, you specify the approval process as one of the following options:

  • Enable policy rules and actions for CA Process Automation.
    Perform this task if any services in the catalog specify the Workflow driven approval process to apply policies. If your implementation uses CA Process Automation for approving and fulfilling requests, you can use CA Process Automation as the engine for policies.
  • Enable policy rules and actions for the Catalog Policy Engine.
    Perform this task if any services in the catalog specify the Policy driven approval process to apply policies. The Catalog Policy Engine is part of the Policy Builder, and is available to all CA Service Catalog implementations. The Catalog Policy Engine does not require CA Process Automation. This approach is typically more efficient and therefore is typically preferred.

If necessary, copy and modify a predefined rule or action to specify a custom rule or action. If both options apply, then you can use either option as the policy engine for any service.

Enable Policy Rules and Actions for CA Process Automation

If any services in your catalog specify the Workflow driven approval process, enable the required rules and actions. If necessary, also enable the policy rules and actions for the Catalog Policy Engine.

Follow these steps:

  1. Click Administration, Events-Rules-Actions.
  2. Click the Event Type named Request/Subscription Item Change.
  3. Select the rule When Status is Submitted and Approval Process is driven by Workflow.
    The Rule Details page for this rule appears. This rule is enabled by default. If it has been disabled, click the Enable button. This button appears on the Rules bar.
  4. Select the action that is named Launch Policy Driven Approval SRF and click the Enable button. The Enable button appears on the Actions bar.
  5. Click Done.
    The Event Details page appears.
  6. To configure CA Service Catalog so that you can use policies to fulfill requests, using simple fulfillment, perform the following actions:
    1. Open the When Status is Pending Fulfillment rule. Do not exit the Event Type named Request/Subscription Item Change.
    2. Create a CA Process Automation action and select the Policy_Approval Start Request Form.
    3. Complete the parameters that appear.
    4. Specify the following parameters as indicated:
    5. RequestStatusUponAssignment =1000
      Specifies that the requested item is set to this status (Pending Fulfillment) when the request pending action is assigned.
    6. RequestStatusUponSuccess =2000
      Specifies that the requested item is set to this status (Fulfilled) when the request pending action is completed.
    The Policy_Approval Start Request Form supports simple fulfillment but does not support multilevel fulfillment and complex fulfillment. However, you can optionally create a CA Process Automation process that does support multilevel fulfillment and complex fulfillment. To do so, use the assignPolicyBasedPendingActions method in the web service named RequestService.

The rules and actions are enabled.

Enable Policy Rules and Actions for Catalog Policy Engine

If any services in your catalog specify the Policy driven approval process, enable the required rules and actions.

Follow these steps:

  1. Click Administration, Events-Rules-Actions.
  2. Click the Event Type named Request/Subscription Item Change.
  3. Locate the rule When Status is Submitted and Approval Process is driven by Policy.
    This rule is enabled by default. If the rule is disabled, select its check box. Click Enable, and click OK.
  4. Click the rule name.
  5. Click the Edit icon for the action Evaluates Policy Driven Approval Process.
    The Edit Action page appears. This action is disabled by default.
  6. Select Enabled in the Status drop-down list, and click OK.
    This action checks the policy setting on the Policies and Actions tab of each service option that triggers the action. According to that setting, the action evaluates global policies, attached policies, or both for the service option.

The rules and actions are enabled.

Step 4 - (Optional) Export and Import Policies

The IXUTIL command-line utility is an importing and exporting command-line utility that allows the preservation and migration of CA Service Catalog data between computers. You can use IXUTIL to export and import new and updated objects, including policies, from one computer to another. You can export and import policies in the following cases:

  • When you upgrade or migrate CA Service Catalog.
  • When you upgrade your computer.
  • When the server fails.

Note: You can also use the Import Export Utility on the product UI to import and export policies.

Follow these steps:

  1. Open the CA Service Catalog command prompt on any Catalog Component computer.
  2. Enter one or more of the following commands:
    • To export all policies in all business units, enter the following command:

      ixutil export policy -f file 
      
    • To export all policies in a business unit, enter the following command:

      ixutil export policy -f file - businessunit businessunit id
      
    • To export a single policy, use the following command:

      ixutil export policy -f file -policy name -businessunit id
      

      If the name contains spaces, enclose the name in double quotation marks.

      ixutil export policy -policy "Mobile Device Policy--Tier 1" ...
      
    • To export multiple policies, enclose the names in double quotation marks, and separate the names with commas.

      ixutil export policy -policy "Mobile Device Policy--Tier 1,Mobile Device Policy--Tier 2,Mobile Device Policy--Tier 3" ...
      
    • To export a folder containing one or more policies, enter the following command:

      ixutil export policy -f file -folder name -businessunit id
      

      To export multiple folders, enclose the names in double quotation marks, and separate the names with commas. Use the previous command for multiple polices as a model.

    • To import a previously exported file containing one or more policies, enter the following command:

      ixutil import policy -f file -businessunit id
      

      The -businessunit businessunit id option is optional when you import the policy file. However, consider the important factors explained in the description of this option later in this topic.

    • To import a previously exported file containing one or more policies in disabled status, enter the following command:

      ixutil import policy -f file -businessunit businessunit id -disable
      
  3. Log in to CA Service Catalog on the computer where you imported the policies. If you had imported policies into a specific business unit, log in to the respective business unit.
  4. Click Catalog, Policies.
  5. Expand the policy folders. Verify that the Catalog system imported the policy or policies as you want.
  6. Close the CA Service Catalog command prompt.

Step 5 - Create a Policy

Administrators create policies to assign approvers automatically for services and service options in a request pending action. In this way, you use policies to manage requests.

Follow these steps:

  1. Click Catalog, Policies.
  2. Select the folder to which you want to add the new policy and click Add, Policy.
  3. Enter an intuitive name for the policy and click OK.
  4. Enter meaningful descriptions in the policy fields for the policy that is created under the parent folder.
  5. Select either High or Low in the Priority drop-down list.

    Note: When a user submits a request, CA Service Catalog checks for and the system applies any matching high-priority policies. Only if no high-priority policy applies to the request, the system checks for and applies any matching low-priority policies.

  6. Select either Active (ready to use the policy) or Inactive in the Status drop-down list.
  7. Save the policy.

Step 6 - Create Conditions for a Policy

Administrators create the condition as the major decision point of the policy. If the condition is met, the Catalog system automatically assigns the pending action to the assignees. You specify the condition using the attributes of CA Service Catalog elements such as users, requests, services, business units. In addition, you can use match functions for creating conditions that are based on service options and service option elements.

Create simple conditions that are based on known attributes, such as category, external_id, code, item type, cost, status. Specify the criteria that the value of the specified attribute must meet to assign the pending action.

The condition builder is the tool in the Condition field that helps you specify valid conditions, one segment at a time. When you initially move the cursor to the field, the condition builder prompts you with valid options for the first part of the condition. These options appear in a drop-down list under the Condition field. Select the option that you want from the list. As you complete each part of the condition, the condition builder continues to prompt you with valid options for the next part. This process continues until the condition is finished, typically with a closing parenthesis.

The condition must be a valid JavaScript expression. Typically specify one condition per policy, using the following format:

$(_.group.attribute operator 'value')

  • group
    Specifies service, request, business unit, or any other group that is illustrated in the types of conditions.
  • attribute
    Specifies any attribute of that group
  • operator
    Specifies one of the following options:
    == (equal to)
    != (not equal to)
    > (greater than)
    < (less than)
    >= (greater than or equal to)
    <= (greater than or equal to)
  • value 
    Specifies a literal value, typically the name of a business unit, request, service, service option group, or user.
    Enter numeric values without quotation marks, for example: $(_.request.bu.status==0).
    Enclose string values in single quotation mark; for example: $(_.request.bu.taxRegion =='South').
    If a string value includes a single or double quotation mark, precede that mark with a backslash (\) as the "escape" character. For example, if the service name is Demandes d'IP Statique, then specify the condition as follows:

    $(_.service.name=='Demandes d\'IP statique')

    As you construct an expression in the Condition Builder, the data type (string or numeric) of the attribute appears on the right, letting you know whether to use quotation marks around the value.

    $(_.service.name=='Procure Server')

    This condition means that when the name of the service is Procure Server, the users you specify are assigned as actors, typically approvers, or fulfillers.
    For example: $(_.request.estimatedCost >==1000)
    This condition assigns the pending action to the specified approvers or fulfillers when the estimated cost of the total request is greater than or equal to $1,000.

Step 7 - Specify Assignees for a Policy

Administrators specify assignees for a policy to configure the Catalog system to assign automatically the request pending action that triggered the policy. If the condition of the policy is met, the Catalog system automatically assigns the request to the specified assignees. The assignees typically process the request by approving, rejecting, or fulfilling it.

To specify assignees for a policy, follow this process:

  1. Review Information about Assignees for Policies
  2. Decide how to Specify Assignees

The Catalog system searches for and assigns approvers and fulfillers in the following order:

  1. A relevant policy
  2. The management hierarchy of the requestor
  3. The Service Provider administrator (spadmin)

Review Information about Assignees for Policies

Assignees are typically request managers or other administrators who act on the requests pending action. The Catalog system assigns these requests, either to the assignees personally or to an administrative group to which they belong.

For example, suppose that the condition specifies that the pending action is triggered when both of the following conditions are true:

  • The name of the requested service is Procure Laptop.
  • The status is Submitted (by default, 200).

In this example, the assignee can be any of the following conditions, depending on the size and scope of the organization:

  • The person or group that approves hardware requests.
  • The manager of the requestor or another manager.
  • The IT Finance Group.
  • The Purchasing department.

You can assign only one approver or several approvers. Thus, you can assign either of the following levels:

  • Only one level of approval, such as the manager only.
  • Several levels of approval, such as the manager first, followed in succession by an IT approver and a financial officer.

When you are creating a policy or editing one, you decide how many approvers and how many levels of approval to specify. Examples follow:

  • For requests to purchase third-party software, the following conditions apply:
    • First, both the immediate manager and the next-level manager must approve the request, in succession.
    • Next, a member of the Software Purchasing department must approve the request.
  • If the Requested For user or the Requested By user is a delegate, include the manager of that user in the list of assignees.
  • If the Requested For user belongs to a specific business unit, specify the approvers or fulfillers for that business unit in the list of assignees.

Decide How to Specify Assignees

Use the following use cases as guidelines:

  • One known user is the assignee. Use either the Action Builder or an API plug-in.
  • Multiple known users at specific levels comprise the list of assignees. Use either the Action Builder or an API plug-in.
  • You query an external system for data to specify the assignees. Use the API plug-in.
  • The identities and number of assignees vary, depending on the data in the request. Use the API plug-in.

Use the Action Builder to Specify Assignees

The Action Builder lets you manually find and select one or more assignees for one or more levels of approval.

Follow these steps:

  1. Click Catalog, Policies, and open the policy.
  2. Add the first assignee by clicking the plus sign (+) in the Action Builder (the box under the Condition field).
  3. Complete the first Requirement field (the one next to the Level 1 column), as follows:
    In the drop-down list, select ANY or ALL.
    • ANY
      • The first approval or fulfillment for a requested item changes the status of the item and closes any remaining pending actions for the item. (Item means a service or service option.)
      • If all users reject or cancel an item, then the item is rejected or canceled.
    • ALL
      • Every assignee must approve or fulfill the requested item.
      • If any assignees are groups, then one member of each assigned group must act on the item.
      • If any assignee cancels or rejects the item, then all pending actions for the item are rejected or canceled.
  4. Complete the first Assignees field (the one next to the first Requirement field) by clicking the magnifying lens:

    Note: In the Find Approvers dialog, if you select User or Group, the name of the next field remains Name Filter. If you select Manager, the name of the next field changes to Manager Level.

    The assignees you selected are recorded. The Find Approvers dialog closes. You return to the Action Builder page.

  5. Click OK under the first row of approvers, and click Save (above the Policy tree).
  6. Specify one or more assignees, as follows:
    If you specify multiple assignees, specify whether the pending actions are to be sequential or parallel.
    Parallel actions occur at the same time and at the same level of approval.
    Sequential actions occur in order, one after the other, and at different levels of approval.
  7. To specify a complex (OR) or compound (AND) expression for the first-level approval, click the first row.
    The Operation field and the second Requirement and Assignees fields open for input.
    1. Complete the second Assignees field and second Requirement fields.
    2. Specify AND to require that both the first and second assignees you specify must approve (or fulfill) the pending action. Otherwise, the pending action is rejected (or is not fulfilled). Specify OR to require that only one of the first and second assignees you specify must approve (or fulfill) the pending action. Otherwise, the pending action is rejected (or is not fulfilled).
    3. Click OK under the first row of approvers, and click Save (above the Policy tree).
    If you are finished specifying approval levels and approvers, navigate away from this window.
  8. To specify a second level of approval, go to the next step.
    Optionally complete the steps for the previous bullet (if applicable) before going to the next step.
  9. If you are finished specifying approval levels and approvers, navigate away from this window.
  10. (Optional) Click the plus sign (+) in the Action Builder to add a second level of approval.
    A second approval row appears, with the fields open for input.
    1. Complete the first Assignees and Requirement fields in this row.
    2. If applicable, specify a complex (either-or) or compound (both-and) expression for this row.
  11. (Optional) Specify a third or more level of approval, until you are finished specifying approvers for this policy.

You have specified the assignees for this policy.

Use an API Plug-in to Specify Assignees

An API plug-in is most useful when you query an external system for data to specify the assignees. An API plug-in is also useful when the identities and number of assignees vary, depending on the data that is supplied in the request. Based on this data, the plug-in dynamically creates the assignee list and specifies the assignee levels.

Follow these steps:

  1. Click Catalog, Policies, and open the policy.
  2. Select Use Plug-in for Assignees. This check box appears under the Condition field.
  3. Complete the fields:
    • Plug-in Id
      Specifies the ID of your custom plug-in for dynamically populating the list of assignees. You or another administrator must have previously written, tested, and loaded this plug-in.
      To view the list of plug-ins, select Administration, Tools, Plug-ins.
    • (Optional) Variables
      Specify the list of variables for the plug-in, if necessary.
      If applicable, open the plug-in that you selected to display its details, including variables. On the details page, the Inputs section lists the ID values and descriptions of the input variables for the plug-in. Copy the ID values of the variables that you want from that page and paste them into the value of the Variables attribute. Enter the variables as a JSON expression.

You have specified assignees for this policy.

Example: Use of Variables

$({'form_field_value':_.sog['sog1'].serviceoption[2].form['form1'].txt1, 'est_service_cost':_.service.estimatedCost, 'est_sog_cost':_.sog['sog1'].estimatedCost, 'req_status':_.request.status})

These variables return data to the plug-in, as follows:

  • form_field_value hold the value of the field named txt1. This field is in the form whose ID is form1. This form is in the service option in row 2 of the service option group whose ID is sog1.
  • If necessary, use the product UI to find the row number of a service option. (The linked topic references policy conditions but the row number has the same value in this context. The row number is an object property that remains constant, whether you reference it in a policy condition, a JSON expression, or another type of code.)
  • est_service_cost holds the estimatedCost property for the service.
  • est_sog_cost holds the estimatedCost property for the service option group.
  • req_status holds the request status.

The data from the variables populates the list of assignees and the levels of approval, according to the code specified in the plug-in. For example, you can write a plug-in to specify that if the following conditions are true, then trigger the following action:

Conditions:

  • If The txt field in form_field_value equals Deluxe.
  • If est_service_cost is greater than 5,000.
  • If est_sog_cost is greater than 500.
  • If req_status equals 200 (Submitted).

Action: Create the following assignment table:

  • Level 1 Assignee is the manager of the IT department.
  • Level 2 Assignee is the manager of the Purchasing department.
  • Level 3 Assignee is the Vice President of the business unit of the requested-for user.

Was this helpful?

Please log in to post comments.