---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Create an ACC policy

# Create an Agent Client Collector policy {#ariaid-title1}

* Release version: Yokohama
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read

Policies consist of the CIs monitored by the Agent Client Collector and the checks that run on those CIs. When creating a policy, you configure a filter which determines the CIs on which the checks are to run. For example, a policy to run checks on all Apache
web servers. You can create new policies or edit the default
policies.

## Before you begin

Role required: agent_client_collector_admin

## About this task

When associating a check definition with a policy, a copy of the definition is created as a check instance. These values appear on the Check Instances tab on the bottom of the Policy
form. Any changes you make to a check instance affect only the instance in the policy; the original check definition remains unchanged. When changing the original check definition, the changes do not apply to already created
check instances. It is recommended you make a copy of a check definition if you are changing its default parameters after having initiated one or more check definitions in a policy.  
Some policy checks require credentials, while others don't. For example:

* The Agent Client Collector does not require credentials for checks that run on its own server. However, when accessing software requiring root or administrator access (such as MySQL), credentials are required.
* When the Agent Client Collector is used as a proxy:
  * Credentials must be invoked to allow the agent to connect to the remote device over SNMP or other protocols.
  * Increase the agent's cpu_percentage_limit value in the acc.yml file, as indicated in the blue box on the Proxy Settings tab.
  {#create-edit-policies__ul_ttn_5rp_54b}
* When the Agent Client Collector uses the HTTP endpoint:
  * If the URL does not require logging in (such as with a public website), no credentials are required.
  * If the URL does require logging in (such as with an API endpoint), credentials are required.
  {#create-edit-policies__ul_vcz_352_h4b}
{#create-edit-policies__ul_j2q_4s2_h4b}

You assign a credential alias in the policy's Credentials tab, as described in the following procedure.

## Procedure

1. Navigate to AllAgent Client CollectorPolicies.
2. Click New.  
   The Policy page appears.
3. Enter values in the fields on the page, as described in the following table:  
   {#create-edit-policies__table_k5m_2ks_rjb__entry__2}

   | Field | Description |
   |-|-|
   | Name | A descriptive name for the policy. |
   | Description | Description of the policy. |
   | Publish status | Hard coded as Draft, which means that the policy has not yet been published. You cannot edit this field. |
   | Hierarchy | Hard coded as None. When a child policy is added to the policy, the value changes to Parent. Child policies have a value of Child. |
   [Table 1. Policy Definition Form]

   {#create-edit-policies__table_k5m_2ks_rjb}
4. On the Monitored CIs tab, select one of the following options:  
   * Manual calculation: Select to exclude the policy from scheduled policy calculation, ignoring any changes to the policy's impacted CIs.

     Select this option when the
     policy monitors a single CI. Otherwise, the Refresh and Publish Monitoring Policies scheduled job takes an abnormally long time to complete.
   * Monitored CI type by filter: Configure the following sub-fields:
     * Monitored CI type: Select the CI type which you want the policy's checks to monitor.
     * Filter: Configure a filter so that the policy's checks monitor only CI types meeting the specified criteria.
     {#create-edit-policies__ul_chb_xgy_vmb}
   * Monitored CI type by script: Enables you to specify the monitored CIs using a script. Using a script allows you to create a CI filter for tables related to each other, and not just for a single table. For example, you can set a filter in both a Linux servers table and an Oracle table when searching for a CI. You return an object containing the table and filter at the end of the script.  
     An example of a script appearing in the Monitored CI Script field is:   

   * Monitored CI type by CMDB Group: Enables you to specify the monitored CIs by using CMDB group queries. When selecting this option, the Monitored CMDB group field appears, where you select a CMDB group to associate with the policy.
     * For details on CMDB groups, see [CMDB groups](https://www.servicenow.com/docs/access?context=cmdb-groups&version=yokohama&pubname=yokohama-servicenow-platform&ft:locale=en-US).
     * For details on building a CMDB query using the CMDB query builder, see [Build a CMDB query using the CMDB query builder](https://www.servicenow.com/docs/access?context=use-cmdb-query-builder&version=yokohama&pubname=yokohama-servicenow-platform&ft:locale=en-US).
     {#create-edit-policies__ul_u31_prq_v4b}
   {#create-edit-policies__ul_tyx_xhg_wmb}
5. Select checks in the Available cell on the Checks tab, and move them to the Selected cell for them to be included in the policy.  
   Checks can be selected multiple times, when you are monitoring more than one process. You can also select a group of checks in the Filter checks by groups field, which presents checks of the selected group in the Available cell.
6. **Optional:** Configure a proxy server on the Proxy Settings tab.  
   Configure a proxy server only when using the agent as a proxy to report data on remote machines. For details, see [Configure an agent on a proxy server](https://servicenow-prod.fluidtopics.net/EMUpKCqNFXTmCJtYHfvNyw "Configure an Agent Client Collector on a proxy server when monitoring services external to the host server, such as URLs or external databases in the cloud.").
7. On the Scheduling tab, select one of the following:  
   * Interval-based scheduling: Configure the time interval (in seconds) to indicate the frequency with which the policy's checks will run.
   * Cron-based scheduling: Enables configuring the policy to be active only during a specific time or time frames.
     1. Select the unlock icon (![Unlock icon]()) to enable selecting cron expressions.
     2. Select the search icon (![Search icon]()) to select a cron expression. Select New to create a new cron expression, or select one of the cron expressions that come with the base system, which are:
        * Every hour nightly 5:00pm-7:00am
        * Every minute daily 8:00am-4:59pm
        * Every minute Mon-Fri 8:00am-4:59pm

        {#create-edit-policies__ul_m1f_vjt_kpb}

        When creating a new cron expression, you must enter it in valid cron format.

        The specified cron expression operates in the time zone of the machine hosting the agent.
     {#create-edit-policies__ol_gff_cgt_kpb}

   {#create-edit-policies__ul_wr4_p2t_kpb}  
   Note:  
   If an Interval or Cron value was specified for the check definition, that value overrides the value configured in either of these fields.
8. On the Credentials tab, select one of the following:  
   * Credential name: Select credentials to be assigned to the policy. The available credentials are those displayed on the associated check definition's Check Secure Parameter Definitions tab.
   * Credential alias: Select the search icon ![Search icon]() to select a credential alias to be used by the policy's checks to connect to the monitored CI. The available options are those created on the Connection \& Credential Aliases page. For details on credential aliases, see [Credential aliases for Discovery](https://www.servicenow.com/docs/access?context=discovery-credential-alias&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).
   {#create-edit-policies__ul_cb2_bhw_54b}
9. Click Save.  
   The following buttons appear:
   * Publish: Publishes the Draft policy, moving its Publish status to Queued. A queued policy is processed by the policy publishing job. The job calculates which agents run the policy and then sends the policy to the relevant MID Servers. The job then moves the policy's Publish status to Published. A published policy is active on the agent.
   * Delete: Deletes the policy.
   {#create-edit-policies__ul_lqx_2ww_2lb}
**Related tasks**   

* [Create a policy hierarchy](https://servicenow-prod.fluidtopics.net/6lruz4fpzr5gEFxiJ8~r3g "Policies are attached to groups of related CIs. If you have a subgroup of related CIs, you can attach a new policy to the subgroup using a policy hierarchy, without creating the new policy from scratch.")

*[\>]: and then