Tips for Writing AI Component Descriptions (Beta)

AI component descriptions are used only in orgs that have Setup with Agentforce (Beta) enabled. For more information about the Setup with Agentforce beta program, see Streamline Administrative Tasks with Setup with Agentforce (Beta).

Setup with Agentforce is a pilot or beta service that is subject to the Beta Services Terms at Agreements - Salesforce.com or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the Product Terms Directory. Use of this pilot or beta service is at the Customer's sole discretion.

When writing an AI-related component description to make your component accessible to Agentforce in Setup, consider these questions to craft a comprehensive description.

  • Audience: Who is the intended user of this component?
  • Functionality: What task or purpose does this component provide?
  • Benefit: Why would someone want to use this component?
  • Context: In which situations or environments is this component typically used?

The more information that you include, the more easily Agentforce can determine whether the component fits a user’s needs when they need help creating a Lightning page.

  • When specifying what the component does and its intended use cases, include detailed examples of scenarios where this component is a good choice.
    • Poor: "A component for adding content," or "For general use."
    • Good: "The component enables users to add and style text content for dashboards, supporting features such as hyperlinks, bullet points, and text alignment. Ideal for adding formatted text sections such as instructions, annotations, or content summaries within dashboards on record pages."
  • Describe in detail the configurable options, limitations, and unique features that differentiate this component from others.
    • Poor: "You can style the text."
    • Good: "...supports text styling features such as bold, italics, underlining, bullet lists, numbered lists, and hyperlink embedding."
  • Mention any limitations or scenarios where the component isn’t suitable. For example, "Doesn’t support dynamic data binding or embedding external media."
  • Avoid technical jargon. Write your description using language that an end user uses to define their requirements.
    • Poor: “This component supports CRUD operations on records.”
    • Good: “This component lets users add, edit, view, and delete records, making it easy to manage and update information displayed on the dashboard.”