assign using active assignment rule checkbox not visible

InfallibleTechie

“assign using active assignment rules” checkbox is not available in salesforce lightning.

Do the following if the “Assign using active assignment rules” checkbox is not available in Salesforce Lightning.

1. Deactivate and reactivate the Assignment Rule.

2. Make sure Case Assignment Checkbox is enabled on the page layout.

Leave a Reply Cancel reply

You must be logged in to post a comment.

• Salesforce Sales Cloud
• Salesforce CPQ / Revenue Cloud
• Salesforce Service Cloud
• Salesforce Experience Cloud
• HubSpot / Pardot / Marketo
• RevOps Tools
• Advisory & Architecture
• Acquisition Integration (Org Merge)
• Salesforce GTM Techstack Roadmap
• Managed Services / Staff Augmentation
• Implementations & Optimizations
• Custom Development / AppExchange
• Custom Training
• Case Studies
• Your Growth Goals

Configuring the “Assign using active assignment rules” checkbox

There are certain behaviors in Salesforce that I classify as particularly pesky. Like the mosquito buzzing your ear while you sleep, kind of pesky. Invariably with these types of problems it becomes worth turning on the proverbial lights, hunting down the offending pest and… well you know, “dealing” with it. It won’t change the world but sure feels better to have done it.

That being said, one of my favorite pesky Salesforce.com problems to have dealt with is controlling the default setting on the “Assign using active assignment rules” checkbox on Lead and Case records.

Description: This checkbox field allows users who have manually created a new Lead or Case record to use the system’s pre-defined assignment rules to route the record to the correct owner/queue. The field appears on the Edit page layout and seems defaulted to the wrong setting for the situation more often than not.

Problem: Unlike normal checkbox fields in Salesforce.com, setting the default behavior for this field is not done in the field edit list on the object and it is not readily apparent where the behavior is set.

Here is the checkbox on the bottom of the Lead layout in edit mode: (Default set to False in both examples)

Here is the checkbox on the bottom of the (open) Case layout in edit mode:

The Solution: For both the Cases and Leads object the default behavior is set in their respective page layouts and if that is not elusive enough, it is buried in the page layout properties option dialog box.

Once you know where to look it is simple to make the needed changes.

Steps to find the behavior options and set defaults to either True or False: (Using Cases object as the example)

• Your Name: Setup:
• In the left-hand menu list select: Cases: Page Layouts: Choose a Page layout
• In the newly presented dialog box, find the  Case Assignment  section: Check or Un-check the checkbox labeled “Select by default”
• Save: the Layout

Screenshot of the edit page for a Case Page layout and the default behavior setting:

Commentary: As frustrating as it is to need to manage the default settings for these checkboxes differently than for other checkboxes, there is merit to the method.

Consider now the value of this more granular control of this field that Salesforce has given you. On normal fields you may only default a checkbox field to True or False and that setting applies across all situations. To create anything more dynamic requires custom engineering. (e.g. triggers, VF pages).

So, here is an example of it in action: Imagine you have enabled Lead assignment rules in your organization. Imagine also that you have both Sales Administrators sales reps that manually enter Leads into the system from time to time.

Sales reps create Leads for themselves so they would prefer to have the Active Assignment default to False whereas the Sales Admin that never owns Leads would prefer to have the Active Assignment default to True. If these checkboxes behaved like ordinary checkboxes you could only satisfy the needs of one group. However, by assigning different page layouts and setting the default behaviors on each layout you can meet the needs of both groups–a novel concept I know.

fast-track your mission critical project

Privacy overview.

the Max Labs place for students

Sorry you're stuck but there's almost always a pretty easy fix!  Do NOT try to start all over again , eg. uninstall Max's Pitch Package, etc. That can make things  worse .

Before you post make sure you check the   Help FAQ   for an instant solution first . Then, if you can't find it there, you can post your problem here and we'll get to it ASAP (within 24 hours), but be sure you:

p ost in the right category

INCLUDE AT LEAST ONE SCREENCAP IN YOUR POST TO SHOW THE PROBLEM!!!!!!!!

explain the problem clearly

Step 110 "Assign using active assignment rule checkbox" not showing up.

For Step 110, after entering the First and Last Name, Company, etc., the step says to check the box that says "Assign using active assignment rule checkbox". However, I do not see the option for that on my screen.

That worked! Thank you.

Awesome! I’m glad. Thanks for letting me know!

Maybe you missed the step where you make the lead assignment rule active. Go back to the rule and check it and edit to check the box for active if it’s not already active.

I tried using Chrome and Safari and this is what I am seeing.

I am also having the same issue. The screen is zoomed out all the way but I still do not see the checkbox.

Try a different browser. Download Firefox or Opera and try that.

If that doesn't work, post a screencap so I can see what you're looking at.

You're zooming out and not, zooming in, right?

Maybe try zooming out your screen. It’s at the very bottom of the pop up window.

SimplySfdc.com

Sunday, december 6, 2020, salesforce: case assignment rules not working.

• Case or Lead Assignment Rules fail to set the Owner
• Assignment rule does not fire on Cases created through Email-to-Case
• Why Salesforce assignment rule is not working?

Thanks for the info..It was helpful

Page-level ad

Dive into the Summer ’24 Release

As an admin, you can help your organization succeed by staying up to date with the latest Salesforce releases and getting familiar with product enhancements.

Check out the Summer ’24 release notes for a list of new features and available updates.

Did you find this helpful?

Help us enhance your experience.

Run Case Assignment Rule from Apex

Case assignment rules allow you to automatically route Cases to the appropriate users or queues. A Case assignment rule consists of multiple rule entries that define the conditions and order for assigning cases. You can create multiple rules (for example, a Standard rule and a Holiday rule), but only one rule can be "active" at a time.

From a standard UI, a user can trigger assignment rules by simply checking the "Assign using active assignment rules" checkbox under the Optional section. The problem arises when your app needs to insert the Case from Apex and wants to trigger assignment rules. Using this script, a Case will be inserted but assignment rules will not be triggered as there is no such field "Assign using active assignment rules" on Case.

Running Case Assignment Rules from Apex A solution is using Database.DMLOptions. The Database.DMLOptions class can provide extra information during a transaction; for example, specifying the truncation behavior of fields or assignment rule information. For example, the script below is fetching the assignment rules of Case and then creating the DMLOptions for the "Assign using active assignment rules" checkbox.

Now when the Case is inserted using this script, the assignment rules get triggered.  

Cookie Consent Manager

General information, required cookies, functional cookies, advertising cookies.

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings. Privacy Statement

Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.

Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.

Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.

Cookie List

About 15 mins

Create Case Queues

Create a case assignment rule, test the case assignment rule.

• Challenge +100 points

Create Case Queues and Assignment Rules

Now that you have your basic support processes and layouts configured for cases, create case queues and assignment rules to route your cases to the correct support teams at Ursa Major Solar.

Create Product Support Tier 1 and Product Support Tier 2 queues so product support cases can be routed to one of these queues based on case criteria and how long the case has been open.

• From Service Setup, enter Queues in the Quick Find box and select Queues .
• Click New  and complete the queue details.
• Label: Product Support Tier 1
• Queue email: [email protected]
• Supported Objects: select Case and click Add .
• Queue Members: Click  User: (Your Name) in the Available Members list, and click Add to add yourself to the Selected Members list.
• Click Save .
• From the Queue   page, click New  and complete the queue details.
• Label:   Product Support Tier 2
• Queue email: [email protected]

Now, create the Inquiry queue for inquiry cases.

• From the Queues page, click New .
• Enter the queue details.
• Label: Inquiry
• Queue Email: [email protected]
• Queue Members: Click User: Ada Balewa in the Available Members list, and click Add to add her to the Selected Members list.

So, now you have case queues set up and ready to handle different types of cases as they’re created. Next, create and activate a standard case assignment rule to assign cases to the correct team members. This is how cases get sent to specific case queues, like the ones you just created.

• From Service Setup, enter Case Assignment Rules in the Quick Find box and select Case Assignment Rules .
• Click New  and enter the rule details.
• Rule Name: Standard Case Assignment
• Select the Active checkbox to make this the active case assignment rule.

Add a rule entry that assigns Product Support cases to the Product Support Tier 1 queue.

• Click the Standard Case Assignment link.
• Under the Rule Entries, click New  and enter the details.

• Click Save & New .

Next, add a rule entry that assigns inquiry cases to the Inquiry queue.

• Enter the details.

Now rename the Automated Case User to System. Every time there’s an automated case change from an assignment rule, for example, the automated case user name will show up in the case history. It will now show an automated “system” change, rather than showing your name as the admin, whenever an automated case change occurs.

• Enter Support Settings in the Quick Find box and select Support Settings .
• Click Edit .

You want to make sure the assignment rules work for Ursa Major Solar by creating a case.

• Click the Contacts tab.
• Select Recently Viewed from the dropdown, and click the Pat Stumuller link.
• In the Cases   related list, click New .
• Select a record type: Product Support .
• Click  Next  and enter the case information.
• Click the Case Number for the case you just created. Ensure that the Case Owner is Product Support Tier 1.

By setting up case queues and assignment rules, cases are now automatically routed to the correct teams. Next, escalate higher priority cases to the Product Support Tier 2 team by creating an Escalation Rule.

• Salesforce Help: Rules
• Salesforce Help: Create Queues
• Salesforce Help: Set Up Assignment Rules
• Get personalized recommendations for your career goals
• Practice your skills with hands-on challenges and quizzes
• Track and share your progress with employers
• Connect to mentorship and career opportunities

• Microsoft Azure
• Google Cloud Platform
• Documentation
• Databricks administration introduction
• Manage users, service principals, and groups

Manage service principals

This article explains how to create and manage service principals for your Databricks account and workspaces.

For an overview of the Databricks identity model, see Databricks identities .

To manage access for service principals, see Authentication and access control .

What is a service principal?

A service principal is an identity that you create in Databricks for use with automated tools, jobs, and applications. Service principals give automated tools and scripts API-only access to Databricks resources, providing greater security than using users or groups.

You can grant and restrict a service principal’s access to resources in the same way as you can a Databricks user. For example, you can do the following:

Give a service principal account admin and workspace admin roles.

Give a service principal access to data, either at the account level using Unity Catalog, or at the workspace level.

Add a service principal to a group at both the account and workspace level, including the workspace admins group.

You can also grant Databricks users, service principals, and groups permissions to use a service principal. This allows users to run jobs as the service principal, instead of as their identity. This prevents jobs from failing if a user leaves your organization or a group is modified.

Unlike a Databricks user, a service principal is an API-only identity; it cannot be used to access the Databricks UI.

Databricks recommends that you enable your workspaces for identity federation . Identity federation enables you to configure service principals in the account console, and then assign them access to specific workspaces. This simplifies Databricks administration and data governance.

If your account was created after November 8, 2023, identity federation is enabled on all new workspaces by default, and it cannot be disabled.

Who can manage and use service principals?

To manage service principals in Databricks, you must have one of the following: the account admin role, the workspace admin role, or the manager or user role on a service principal.

Account admins can add service principals to the account and assign them admin roles. They can also assign service principals to workspaces, as long as those workspaces use identity federation.

Workspace admins can add service principals to a Databricks workspace, assign them the workspace admin role, and manage access to objects and functionality in the workspace, such as the ability to create clusters or access specified persona-based environments.

Service Principal Managers can manage roles on a service principal. The creator of a service principal becomes the service principal manager. Account admins are service principal managers on all service principals in an account.

If a service principal was created before June 13, 2023, then the creator of the service principal does not have the service principal manager role by default. Ask an account admin to grant you the service principal manager role.

Service Principal Users can run jobs as the service principal. The job runs using the identity of the service principal, instead of the identity of the job owner. For more information, see Run a job as a service principal .

Service principal Users that are workspace admins can also create tokens on behalf of the service principal.

When the RestrictWorkspaceAdmins setting on a workspace is set to ALLOW ALL , workspace admins can create a personal access token on behalf of any service principal in their workspace. See Restrict workspace admins .

For information on how to grant the service principal manager and user roles, see Roles for managing service principals .

Manage service principals in your account

Account admins can add service principals to your Databricks account using the account console.

Add service principals to your account using the account console

As an account admin, log in to the account console .

In the sidebar, click User management .

On the Service principals tab, click Add service principal .

Enter a name for the service principal.

Click Add .

Assign account admin roles to a service principal

On the Service principals tab, find and click the username.

On the Roles tab, turn on Account admin or Marketplace admin .

Assign a service principal to a workspace using the account console

To add users to a workspace using the account console , the workspace must be enabled for identity federation. Workspace admins can also assign service principals to workspaces using the workspace admin settings page. For details, see Add a service principal to a workspace using the workspace admin settings .

In the sidebar, click Workspaces .

Click your workspace name.

On the Permissions tab, click Add permissions .

Search for and select the service principal, assign the permission level (workspace User or Admin ), and click Save .

Remove a service principal from a workspace using the account console

To remove service principals from a workspace using the account console, the workspace must be enabled for identity federation. When a service principal is removed from a workspace, the service principal can no longer access the workspace, however permissions are maintained on the service principal. If the service principal is later added back to the workspace, it regains its previous permissions.

As an account admin, log in to the account console

On the Permissions tab, find the service principal.

On the confirmation dialog, click Remove .

Deactivate a service principal in your Databricks account

Account admins can deactivate service principals across a Databricks account. A deactivated service principal cannot authenticate to the Databricks account or workspaces. However, all of the service principal’s permissions and workspace objects remain unchanged. When a service principal is deactivated the following is true:

The service principal cannot authenticate to the account or any of their workspaces from any method.

Applications or scripts that use the tokens generated by the service principal are no longer able to access the Databricks API. The tokens remain but cannot be used to authenticate while a service principal is deactivated.

Clusters owned by the service principal remain running.

Scheduled jobs created by the service principal fail unless they are assigned to a new owner.

When a service principal is reactivated, it can login to Databricks with the same permissions. Databricks recommends deactivating service principals from the account instead of removing them because removing a service principal is a destructive action. See Remove service principals from your Databricks account . When you deactivate a service principal from the account, that service principal is also deactivated from their identity federated workspaces.

You cannot deactivate a user using the account console. Instead, use the Account Service Principals API. See Deactivate a service principal using the API .

Remove service principals from your Databricks account

Account admins can delete service principals from a Databricks account. Workspace admins cannot. When you delete a service principal from the account, that principal is also removed from their workspaces.

When you remove a service principal from the account, that service principal is also removed from their workspaces, regardless of whether or not identity federation has been enabled. We recommend that you refrain from deleting account-level service principals unless you want them to lose access to all workspaces in the account. Be aware of the following consequences of deleting service principals:

Applications or scripts that use the tokens generated by the service principal can no longer access Databricks APIs

Jobs owned by the service principal fail

Clusters owned by the service principal stop

Queries or dashboards created by the service principal and shared using the Run as Owner credential have to be assigned to a new owner to prevent sharing from failing

To remove a service principal using the account console , do the following:

As an account admin, log in to the account console.

In the confirmation dialog box, click Confirm delete .

Manage service principals in your workspace

Workspace admins can manage service principals in their workspaces using the workspace admin settings page.

Add a service principal to a workspace using the workspace admin settings

As a workspace admin, log in to the Databricks workspace.

Click your username in the top bar of the Databricks workspace and select Settings .

Click on the Identity and access tab.

Next to Service principals , click Manage .

Click Add service principal .

Select an existing service principal to assign to the workspace or click Add new to create a new one.

If your workspace is not enabled for identity federation , you cannot assign existing account service principals to your workspace.

Assign the workspace admin role to a service principal using the workspace admin settings page

Next to Groups , click Manage .

Select the admins system group.

Click Add members .

Select the service principal and click Confirm .

To remove the workspace admin role from a service principal, remove the service principal from the admin group.

Deactivate a service principal in your Databricks workspace

Workspace admins can deactivate service principals in a Databricks workspace. A deactivated service principal cannot access the workspace from Databricks APIs, however all of the service principal’s permissions and workspace objects remain unchanged. When a service principal is deactivated:

The service principal cannot authenticate to the workspaces from any method.

The service principal’s status shows as Inactive in the workspace admin setting page.

Applications or scripts that use the tokens generated by the service principal can no longer access the Databricks API. The tokens remain but cannot be used to authenticate while a service principal is deactivated.

Scheduled jobs created by the service principal have to be assigned to a new owner to prevent them from failing.

When a service principal is reactivated, it can authenticate to the workspace with the same permissions. Databricks recommends deactivating service principals instead of removing them because removing a service principal is a destructive action.

Select the service principal you want to deactivate.

Under Status , uncheck Active .

To set a service principal to active, perform the same steps, but check the checkbox instead.

Remove a service principal from a workspace using the workspace admin settings page

Removing a service principal from a workspace does not remove the service principal from the account. To remove a service principal from your account, see Remove service principals from your Databricks account .

When a service principal is removed from a workspace, the service principal can no longer access the workspace, however permissions are maintained on the service principal. If the service principal is later added back to a workspace, it regains its previous permissions.

Select the service principal.

In the upper-right corner, click Delete .

Click Delete to confirm.

Manage service principals using the API

Account admins and workspace admins can manage service principals in the Databricks account and workspaces using Databricks APIs. To manage roles on a service principal using the API, see Manage service principal roles using the Databricks CLI .

Manage service principals in the account using the API

Admins can add and manage service principals in the Databricks account using the Account Service Principals API. Account admins and workspace admins invoke the API using a different endpoint URL:

Account admins use {account-domain}/api/2.0/accounts/{account_id}/scim/v2/ .

Workspace admins use {workspace-domain}/api/2.0/account/scim/v2/ .

For details, see the Account Service Principals API .

Deactivate a service principal using the API

Account admins can change a service principal’s status to false to deactivate the service principal using the Account Service Principals API .

For example:

update-sp.json :

A deactivated service principal’s status is labeled Inactive in the account console. When you deactivate a service principal from the account, that service principal is also deactivated from its workspaces.

Manage service principals in the workspace using the API

Account and workspace admins can use the Workspace Assignment API to assign service principals to workspaces enabled for identity federation. The Workspace Assignment API is supported through the Databricks account and workspaces.

Account admins use {account-domain}/api/2.0/accounts/{account_id}/workspaces/{workspace_id}/permissionassignments .

Workspace admins use {workspace-domain}/api/2.0/preview/permissionassignments/principals/{principal_id} .

See Workspace Assignment API .

If your workspace is not enabled for identity federation, a workspace admin can use the workspace-level APIs to assign service principals to their workspaces. See Workspace Service Principals API .

Manage tokens for a service principal

Service principals can authenticate to APIs on Databricks by using Databricks OAuth tokens or Databricks personal access tokens, as follows:

Databricks OAuth tokens can be used to authenticate to Databricks account-level and workspace-level APIs.

Databricks OAuth tokens that are created at the Databricks account level can be used to authenticate to Databricks account-level and workspace-level APIs.

Databricks OAuth tokens that are created at the Databricks workspace level can be used to authenticate only to Databricks workspace-level APIs.

Databricks personal access tokens can be used to authenticate only to Databricks workspace-level APIs.

Manage Databricks OAuth authentication for a service principal

To authenticate to account-level and workspace-level Databricks REST APIs, account admins can use Databricks OAuth tokens for service principals. You can request an OAuth token using the client ID and a client secret for the service principal. For more information, see OAuth machine-to-machine (M2M) authentication .

Manage personal access tokens for a service principal

To authenticate a service principal to workspace-level APIs on Databricks only, a workspace admin that is a Service Principal User can create a Databricks personal access tokens on behalf of the service principal, as follows:

You cannot use the Databricks user interface to generate Databricks personal access tokens for Databricks service principals. This process uses Databricks CLI version 0.205 or above to generate an access token for a Databricks service principal. If you do not already have the Databricks CLI installed, see Install or update the Databricks CLI .

Set up authentication for the Databricks CLI, if you have not done so already. One way to set this up is by using Databricks personal access token authentication for your Databricks workspace user first. See Databricks personal access token authentication .

Get the application ID for the Databricks service principal, if you do not already have it available:

If the admin console for your workspace is not already open, click your username in the workspace’s top bar and click Settings .

Under Workspace admin , click Identity and access .

Click the name of the Databricks service principal to open its settings page. If the name is not visible, use Filter service principals to find it.

On the Configurations tab, note the Application Id value.

Use the Databricks CLI to run the following command, which generates the access token for the Databricks service principal.

In the following command, replace these placeholders:

Replace <application-id> with the application ID of the Databricks service principal.

Replace <lifetime-seconds> with the number of seconds that the access token is valid for. For example, 1 day is 86400 seconds.

Optionally, replace <comment> with any meaningful comment about the access token’s purpose. If the --comment option is not specified, then no comment is generated.

Optionally, replace <profile-name> with the name of a Databricks configuration profile that contains authentication information for your Databricks user and target workspace. For instance, see Databricks personal access token authentication . If the -p option is not specified, the Databricks CLI will attempt to find and use a configuration profile named DEFAULT .

In the response, copy the value of token_value , which is the access token for your Databricks service principal.

Be sure to save the copied token in a secure location. Do not share your copied token with others. If you lose the copied token, you cannot regenerate that exact same token. Instead, you must repeat this procedure to create a new token.

If you are not able to create or use tokens in your workspace, this might be because your workspace administrator has disabled tokens or has not given you permission to create or use tokens. See your workspace administrator or the following:

Enable or disable personal access token authentication for the workspace

Personal access token permissions

A service principal can then use its own Databricks personal access token to create additional Databricks personal access tokens for itself, as follows:

This procedure assumes that you have already generated the first Databricks personal access token for the Databricks service principal. You use this access token to set up the Databricks CLI to authenticate the Databricks service principal so that it can then generate additional access tokens for itself. See Databricks personal access token authentication .

Use the Databricks CLI to run the following command, which generates another access token for the Databricks service principal.

Optionally, replace <lifetime-seconds> with the number of seconds that the access token is valid for. For example, 1 day is 86400 seconds. If the --lifetime-seconds option is not specified, the access token is set to never expire (not recommended).

Optionally, replace <profile-name> with the name of a Databricks configuration profile that contains authentication information for the Databricks service principal and the target workspace. If the -p option is not specified, the Databricks CLI will attempt to find and use a configuration profile named DEFAULT .

In the response, copy the value of token_value , which is the access token for the Databricks service principal.