Agentforce Platform | Query Records

Action Details

Considerations

For overall considerations for Agentforce, see Agentforce Considerations

• This action supports only English language.
• This action works with any searchable and queryable standard objects supported by the User Interface API and any searchable custom objects. External objects are not supported.
• Queries with data from multiple objects aren’t supported. For example, a user can’t view their leads and opportunities with one request.
• This action can filter search results by querying up to one parent-to-child or child-to-parent relationship. For example, a user can ask: "What's the average amount of closed opportunities that have an account based in the United States?"
• Queries that retrieve data based on a lookup field, related list, or a picklist don’t always work.
• The maximum number of results displayed is 50, even if more than 50 matching results are found.
• Field normalization isn’t available, so retrieving records based on field values is format-dependent. For example, the user request “Get my contact with phone number 415-123-4567” returns results only if the phone number is entered in the exact same format.
• Queries with ambiguous filter or sort criteria are determined by the LLM. No specific business rules are used. For example, if a user requests their “top” opportunity, the LLM can interpret “top” to mean the opportunity with the highest amount or soonest close date. If you have questions about the criteria used to retrieve the search results, view the plan in Agentforce Builder.
• Synonyms are supported for common standard objects and fields. For example, if a user’s request includes the word “deal,” the action can determine that the user is referring to an opportunity. Customization of synonyms isn’t supported. Synonyms for custom objects or fields aren’t always interpreted accurately.
• A limited set of default standard fields for the Account, Contact, Case, Opportunity, and Lead objects are supported. Other fields are supported only if they're included in the queried object’s default searchable layout and the default record page layout. If the object has a large number of fields, the action can limit the number of fields included in the search.
• When results are returned, the displayed fields come from two sources: up to three fields from the query and up to 10 fields from the object’s search layout. These sets are merged, and any field that appears in both is counted only once. As a result, the number of displayed fields varies and isn’t always a fixed total of 10. If the query has fewer than three fields, only those queried fields are included from the query. If the query has more than three fields, only three are included.
  • Fewer than three query fields: For example, if a user asks to see their opportunities sorted by rating, the query contributes two fields (Opportunity Name and Rating), and the search layout contributes five fields (Opportunity Name, Stage, Close Date, Owner, and Account Name). Because Opportunity Name appears in both sources, it’s counted only once, so the user sees six fields.
  • More than three query fields: For example, if a user asks to see their accounts with the name, industry, annual revenue, and phone, the query has four fields, so only the first three are kept: Account Name, Industry, and Annual Revenue. Phone is dropped from the query, though it can still appear if it’s part of the account search layout.
• Results are returned only when the full search criteria are met. Partial results aren’t supported. If a user requests information based on two fields but they only have access to one of those fields, the query returns an error instead of returning results based on just one of the fields.
• Implicit field lookups aren't fully supported. To retrieve records with a specific field match, mention the precise field and value in the query. For example, for more accurate results, a user can enter, “List my accounts that have an Industry of Technology” rather than "List my technology accounts."