Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short answer: you cannot create a custom index yourself. You open a case with Salesforce Support, show them the query and the selectivity, and they add it. The exception is that external ID and unique fields get one automatically, which is why marking a field as an external ID is usually the fastest route to an index.

What you already have without asking

Several fields are indexed by default on every object. Id, Name, OwnerId, CreatedDate, SystemModstamp, RecordTypeId, the division field if divisions are enabled, and every lookup or master-detail relationship field. Those cover more queries than people expect. Before filing a case, check whether restructuring the filter to use one of them solves the problem.

On top of that, two field settings create an index as a side effect:

  • External ID. Tick the box on a text, number, email or auto number field and you get an index. This is the shortcut. It also enables upsert by that field, which you may or may not want.
  • Unique. A unique constraint is enforced by an index, so you get one for free. Only useful if the values genuinely are unique.

Both are self-service and cost nothing. If the field can reasonably be an external ID, stop reading and go tick the box.

What qualifies for a support-created index

Support will consider an index when the field is a normal, filterable scalar: text, number, date, datetime, checkbox, picklist and lookup fields. The request succeeds far more often when you bring evidence.

The evidence that works:

  • The exact SOQL or report, with the filter you need indexed.
  • The row count on the object and the row count the filter returns.
  • Query Plan output showing a TableScan leading operation.
  • A statement of business impact: this report times out, this integration fails nightly.

Selectivity is the thing they will check. A custom index is used only when the filter matches under 10% of the first million records and under 5% beyond that, capped at 333,333 rows. A field where 60% of records share a value will not benefit, and Support may decline on that basis even though the index technically exists.

What cannot be indexed

Some fields are off the table regardless of how good your case is:

  • Formula fields that are not deterministic. A formula referencing TODAY(), NOW(), another object’s fields through a lookup, or a rolling calculation cannot be indexed because its value changes without a record edit.
  • Long text area and rich text fields.
  • Multi-select picklists for the usual filter operators.
  • Encrypted fields under classic encryption.
  • Fields on some standard objects where the platform already manages the index strategy.

Deterministic formulas, the ones built only from fields on the same record with no date functions, can be indexed. That is a genuinely useful escape hatch when the filter you need is a combination of two fields.

Filters that defeat any index

An index on the right field still does nothing if the query shape prevents its use. The common offenders are !=, NOT, a leading wildcard in LIKE '%x', and OR across fields where not every branch is independently indexed. Null comparisons need an index that includes nulls, which Support can build specifically if you ask for it.

How to file it

Open a case in Help &amp. Training, choose the platform performance product area, and include everything above in the first message. Name the org and the object. A well-evidenced request tends to come back in a few days. A request that says “queries are slow” comes back asking for evidence, and you have lost a week.

Indexes are applied per org. Getting one in production does not give you one in your sandboxes, so mention every environment you need it in, and re-request after a full sandbox refresh if the index does not carry.

When the answer is not an index

If the filter is genuinely non-selective, no index will help. The fixes then are architectural: add a discriminating field that is selective (a status flag that is true for the small set you query), archive old rows out of the object, use a skinny table for the report case, or restructure so the query filters on an indexed lookup first.

Frequently asked

Does a custom index cost anything? No licence cost. It adds a small amount of write overhead on every insert and update to that object, which is almost never noticeable.

Can I see which fields are indexed? Object Manager shows an Indexed column on the field list, and Query Plan names the index a plan would use.

Will Support index a field so a report runs faster? Yes, reports use the same optimiser. You just have less visibility into whether it worked, so test with an equivalent SOQL query.