{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":3719,"path":"build-workflows/approvals/t_SetUpAGatingApprViaApprovalRule.md","title":"Set up a gating approval via an approval rule","bundle":null,"doc_type":null,"release":"australia","body":"\n# Set up a gating approval via an approval rule\n\nYou can set up a gating approval via an approval rule.\n\n**Important:** Classic approval rules have been replaced by the Workflow Studio [Ask for Approval action](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/build-workflows/workflow-studio/ask-approval-flow-designer.md). Use Workflow Studio to create workflow-driven approval logic that is easier to maintain and provides better reporting information.\n\n## Before you begin\n\nRole required: admin\n\n## Procedure\n\n1.  From the left navigation pane, select **System Policy** &gt; **Approval Rules**.\n\n2.  Click **New**.\n\n    \\[Omitted image \"ApprovalRule.png\"\\] Alt text: Approval rule\n\n<table id=\"table_n5t_lpl_sr\"><thead><tr><th>\n\nField\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td>\n\nName\n\n</td><td>\n\nName of this rule.\n\n</td></tr><tr><td>\n\nTable\n\n</td><td>\n\nTask table to which this rule applies. For most service catalog approvals, select **Request**.\n\n**Note:** The list shows only tables and database views that are [Application scope](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/application-development/c_ApplicationScope.md) as the approval rule.\n\n</td></tr><tr><td>\n\nActive\n\n</td><td>\n\nIndicator of whether the rule is active \\(defaults to true\\).\n\n</td></tr><tr><td>\n\nRun Rule Before\n\n</td><td>\n\nIndicator of whether the rule runs before or after the request record is saved. For most approvals, select this check box.\n\n</td></tr><tr><td>\n\nUser\n\n</td><td>\n\nUser who must approve this request \\(can be empty\\).\n\n</td></tr><tr><td>\n\nGroup\n\n</td><td>\n\nGroup that must approve this request \\(can be empty\\).\n\n</td></tr><tr><td>\n\nSet State\n\n</td><td>\n\nValue of the approval field on the task in after this rule runs. In most cases, select **Requested**.\n\n</td></tr><tr><td>\n\nCondition\n\n</td><td>\n\nCondition under which the rule applies.\n\n</td></tr><tr><td>\n\nScript\n\n</td><td>\n\nAn optional server script to programmatically specify who the approver should be. For example, for the one-line script `current.requested_for.manager`, ServiceNow checks the requested\\_for reference field on the current record. It then locates the manager field on the referenced record and assigns that person as the approver. For other examples, see the Script field on approval rules provided by ServiceNow.\n\n</td></tr></tbody>\n</table>    Notes and limitations:\n\n    1.  You can have as many rules as you want on a given table. If more than one rule applies, you will get more than one approver.\n    2.  You can't get duplicate approvers, for example, if two rules both want Fred Luddy to approve a particular request, the system will only create one approval entry for him.\n    3.  By default all requests start out in a **Not yet requested** approval state. Approval notifications will not go out until the request's approval state is set to **Requested**. You can do that manually, or you can do it in script, but the easiest way to do it is to use the **Set State** field to automatically set the request to **Requested**.\n\n"}}