> For the complete documentation index, see [llms.txt](https://docs.docontrol.io/docontrol-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docontrol.io/docontrol-user-guide/risk-management/threat-model-coverage/it-and-security-operations/salesforce-playbooks-for-it-and-security-operations.md). # Salesforce playbooks for IT and security operations To mitigate the risk associated with IT and security operations in Salesforce, you can define automated workflows for these use cases: * [Detect login from disabled accounts](#detect-login-from-disabled-accounts) * [Detect suspicious login attempt](#detect-suspicious-login-attempt) * [Notify on suspicious API query in Salesforce](#notify-on-suspicious-api-query-in-salesforce) ## Detect login from disabled accounts When a blocked or inactive user tries to log into Salesforce from a disabled account, the Security Ops team is automatically notified by email and Slack. 1. In Workflows, select **Playbooks**. 2. Filter the playbooks according to IT and security operations, and select the **Detect login from disabled accounts** playbook. 3. Give an action name.

4. Customize the Salesforce `Login` event trigger. 5. Customize the **Conditional** step: Is the user not blocked? 6. If **true** (the user is not blocked): * Customize another **Conditional** step: Is the user active? * If **true**: End the workflow. * If **false**: Link to **Notify by email** step. 7. If **false** (the user is blocked): * Customize the **Notify by email** step to notify the Security team that DoControl detected a suspicious login attempt. * Customize the **Notify in Slack** step to notify the SecOps incident channel that DoControl detected a suspicious login attempt. ## Detect suspicious login attempt When a user tries to log into Salesforce from a non-trusted IP, not allowed country, with a failed login or unsecured session, the Security Ops team is automatically notified by email and Slack. 1. In Workflows, select **Playbooks**. 2. Filter the playbooks according to IT and security operations, and select the **Detect suspicious login attempt** playbook. 3. Give an action name.

4. Customize the Salesforce `Login` event trigger. 5. Customize the **Conditional** step: Is the user IP from the trusted IP list? * If **true**, customize the **Conditional** step: Is the country allowed? * If **false**, customize the **Notify by email** and **Notify in Slack** steps to notify the Security team and SecOps incident channel that DoControl detected a suspicious login attempt. 6. For the **Conditional** step: Is the country is allowed? * If **true**, customize the **Conditional** step: Did the login succeed? * If **false**, customize the **Notify by email** and **Notify in Slack** steps to notify the Security team and SecOps incident channel that DoControl detected a suspicious login attempt. 7. For the **Conditional** step: Did the login succeed? * If **true**, customize the **Conditional** step: Is the session secured? * If **false**, customize the **Notify by email** and **Notify in Slack** steps to notify the Security team and SecOps incident channel that DoControl detected a suspicious login attempt. 8. For the **Conditional** step: Is the session secured? * If **true**, end the workflow. * If **false**, customize the **Notify by email** and **Notify in Slack** steps to notify the Security team and SecOps incident channel that DoControl detected a suspicious login attempt. ## Notify on suspicious API query in Salesforce When a suspicious API query is detected by Salesforce, the Security Ops team is automatically notified by Slack and the Datadog logs are sent. 1. In Workflows, select **Playbooks**. 2. Filter the playbooks according to IT and security operations, and select the **Notify on suspicious API query in Salesforce** playbook. 3. Give an action name.

4. Customize the Salesforce `API anomaly` event trigger. 5. Customize the **Conditional** step: Is the user about to be terminated? 6. If **true**, and the user is about to be terminated: * Customize the **Get user metadata** step to retrieve employee data from your integrated HRIS app (HiBob or Workday). * Send a message to the Security team via the **Notify in Slack** step, informing them that an about-to-be-terminated employee just performed a suspicious API action in Salesforce. * Send a message to the user's manager via the **Notify in Slack** step, informing them that an about-to-be-terminated employee just performed a suspicious API action in Salesforce. * Customize the **Send logs** step to send a log record to your Datadog platform over HTTP. 7. If **false**, customize another **Conditional** step: is the user a guest or integration user? * If **true**, and the user is a guest or integration user: Send a message to the Security team and SecOps incident channel via the **Notify in Slack** step, informing them that an about-to-be-terminated employee just performed a suspicious API action in Salesforce. * Customize the **Send logs** step to send a log record to your Datadog platform over HTTP. 8. If **false** (the user is not a guest or integration user): * Send a message to the Security team via the **Notify in Slack** step, informing them that an about-to-be-terminated employee just performed a suspicious API action in Salesforce. * Customize the **Send logs** step to send a log record to your Datadog platform over HTTP. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.docontrol.io/docontrol-user-guide/risk-management/threat-model-coverage/it-and-security-operations/salesforce-playbooks-for-it-and-security-operations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.