You can define requests for end users to select in the Homepage screen.
The requests can be handled either manually by an analyst or by using a
Playbook thereby automating the request process and turning the platform
into an internal ticketing system between different teams such as IT to the
SOC, or from an MSSP to an end user. Each request enters the platform as a
Case with the label "Request" on it to clearly define it.
Examples of such requests can be
anything from Blocking malicious IPs to Optimizing SIEM rules and even
Onboarding a new user.
In this article we will demonstrate how to create
a specific request template and show the end-to-end flow.
Scenario: I am a SOC Manager and I want to allow my SOC team to open a
request to add permissions for internal users to our Salesforce.
Google recommends taking some time to plan out what requests can be
automated and how to build the accompanying playbook.
To define a request for Salesforce
permissions:
Navigate to Settings > Environments >
Requests.
Click on the Add Requests + icon at the top right of the
screen.
After adding a logical name and environment, you need to select
a Request Type. This type is essentially the category that the request
falls under. The type that you choose here will determine what entities
display in the Event Fields drop down below. In this example we will
choose Login.
The
Event Fields provide a way for the platform to recognize the incoming case
request and perform the appropriate "mapping and modelling" behind the
scenes. In the first field, you need to manually enter the field
name. Next, choose the type of field, for example email or
string. In the watermark field, add an instruction for the requester
which explains what they need to add here. In the final field you can
choose to use an Event Field (which will bring a raw event into the
system) or use entities which you can use in Playbooks later on. In the
example below, we are using the Username and the SourceUserName
entity.
Click Add.
Build Playbook
The next step will be to build a playbook that will
automatically run once the new Case Request enters the Platform. The
following procedure provides an illustration of building a specific Playbook
for this specific Request.
Create a new playbook with appropriate name and
environment.
Choose Alert Type Trigger. Equals to Salesforce Permission
Approvals (this is the template we created previously in the Settings
screen).
Add Active Directory - Enrich
Entities to get more information on the user.
Active Directory - Add User to Group.
Make sure to fill out parameters as follows: Action Type:
Manual - this means that the Playbook will stop running and wait
for further instructions Assign To: Administrator -
the step can be assigned to either a specific user or a SOC Role and will
be displayed as a Pending Action on both the Homepage and in the Case
View. Message to
Assignee: Please approve or decline permission for user
[Entity.Identifier] to
Salesforce group. The message will appear as part of the Pending
Action details. Time to respond - enable this timer
and give the assigned user a day by which to respond.
Add Siemplify Close Case Action. This
closes the Playbook after the admin has approved/declined the request.
The request has now been created
with the corresponding Playbook.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eThis guide details how to define and automate user requests within the Google SecOps platform, enabling the creation of an internal ticketing system.\u003c/p\u003e\n"],["\u003cp\u003eRequests are initiated by end users, handled as Cases labeled "Request," and can cover various needs such as blocking IPs, optimizing SIEM rules, or onboarding new users.\u003c/p\u003e\n"],["\u003cp\u003eAdministrators define request templates in Settings, specifying the request type, required event fields, and instructions for the requester.\u003c/p\u003e\n"],["\u003cp\u003ePlaybooks can be created to automate the processing of requests, exemplified by a scenario where a request for Salesforce permissions triggers an Active Directory update and requires admin approval.\u003c/p\u003e\n"],["\u003cp\u003ePending request actions are visible and can be managed from multiple locations, including the Cases screen and the Homepage's Pending Actions tab, with different interaction options for standard and collaborator users.\u003c/p\u003e\n"]]],[],null,["# Define Requests for Users (Admin)\n=================================\n\nSupported in: \nGoogle secops [SOAR](/chronicle/docs/secops/google-secops-soar-toc) \nYou can define requests for end users to select in the Homepage screen.\nThe requests can be handled either manually by an analyst or by using a\nPlaybook thereby automating the request process and turning the platform\ninto an internal ticketing system between different teams such as IT to the\nSOC, or from an MSSP to an end user. Each request enters the platform as a\nCase with the label \"Request\" on it to clearly define it.\n\nExamples of such requests can be\nanything from Blocking malicious IPs to Optimizing SIEM rules and even\nOnboarding a new user.\n\nIn this article we will demonstrate how to create\na specific request template and show the end-to-end flow.\n\nScenario: I am a SOC Manager and I want to allow my SOC team to open a\nrequest to add permissions for internal users to our Salesforce.\n\nStep One: [Define Request](#firstanchor)\n\nStep Two: [Build Playbook](#secondanchor)\n\n### **Define Request**\n\nGoogle recommends taking some time to plan out what requests can be\nautomated and how to build the accompanying playbook.\n\nTo define a request for Salesforce\npermissions:\n\n1. Navigate to Settings \\\u003e Environments \\\u003e Requests.\n2. Click on the Add Requests + icon at the top right of the screen.\n3. After adding a logical name and environment, you need to select a Request Type. \n This type is essentially the category that the request falls under. The type that you choose here will determine what entities display in the Event Fields drop down below. In this example we will choose Login.\n4. The Event Fields provide a way for the platform to recognize the incoming case request and perform the appropriate \"mapping and modelling\" behind the scenes. In the first field, you need to manually enter the field name. \n Next, choose the type of field, for example email or string. \n In the watermark field, add an instruction for the requester which explains what they need to add here. \n In the final field you can choose to use an Event Field (which will bring a raw event into the system) or use entities which you can use in Playbooks later on. In the example below, we are using the Username and the SourceUserName entity. \n [](/static/chronicle/images/soar/definerequests1.png)\n5. Click Add.\n\n### **Build Playbook**\n\nThe next step will be to build a playbook that will\nautomatically run once the new Case Request enters the Platform. The\nfollowing procedure provides an illustration of building a specific Playbook\nfor this specific Request.\n\n1. Create a new playbook with appropriate name and environment.\n2. Choose Alert Type Trigger. Equals to Salesforce Permission Approvals (this is the template we created previously in the Settings screen). \n [](/static/chronicle/images/soar/definerequests2.png)\n3. Add Active Directory - Enrich Entities to get more information on the user. \n [](/static/chronicle/images/soar/definerequests3.png)\n4. Active Directory - Add User to Group. Make sure to fill out parameters as follows: \n **Action Type:\n Manual** - this means that the Playbook will stop running and wait for further instructions \n **Assign To: Administrator** - the step can be assigned to either a specific user or a SOC Role and will be displayed as a Pending Action on both the Homepage and in the Case View. \n **Message to\n Assignee: Please approve or decline permission for user\n \\[Entity.Identifier\\] to\n Salesforce group.** The message will appear as part of the Pending Action details. \n **Time to respond -** enable this timer and give the assigned user a day by which to respond. \n [](/static/chronicle/images/soar/definerequests4.png)\n5. Add Siemplify Close Case Action. This closes the Playbook after the admin has approved/declined the request. \n [](/static/chronicle/images/soar/definerequests5.png)\n\nThe request has now been created\nwith the corresponding Playbook.\n\n[Click here to see how the user chooses the request.](/chronicle/docs/soar/overview-and-introduction/your-workdesk/filling-out-request-from-workdesk)\n\nOnce the user has chosen the request, it will enter the system as a Request Case.\n[](/static/chronicle/images/soar/definerequests6.png)\n\nThe Playbook is waiting for the Admin's input to continue.\n\n### How can I approve the request?\n\nThere are three places in the Platform that you can navigate to\nin order to see the Pending Request.\n\n1. Cases screen - Click over to the Playbooks tab under the correct Alert and click the Execute button in the side drawer to approve the request. \n [](/static/chronicle/images/soar/definerequests7.png)\n2. Cases screen - Overview. Click the Execute button in the appropriate widget.\n3. Homepage - Click over to the Pending Actions tab and select the Required Pending Action. Click Execute to approve the request.\n\n[](/static/chronicle/images/soar/definerequests8.png) **Note:** Standard users will see the Execute/Skip options. The collaborator user will see Approve/Decline options and be asked to provide a reason if they decline the Action.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]