> For the complete documentation index, see [llms.txt](https://docs.avonnicomponents.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.avonnicomponents.com/app-builder-components/getting-started/understanding-the-essentials/component-properties-reference.md). # Component Properties Reference Quick reference guide for common property patterns used across Avonni App Builder Components. **Related Pages:** * [**Core Concepts**](/app-builder-components/getting-started/understanding-the-essentials/core-concepts.md) - Learn fundamental principles * [**Common Use Case Patterns**](/app-builder-components/getting-started/understanding-the-essentials/common-use-case-patterns.md) - Pre-built configuration examples * [**Troubleshooting & FAQs**](/app-builder-components/resources/troubleshooting-and-faqs.md) - Solutions to common problems *** ## Filter The **Filter** property uses SOQL WHERE clause syntax to limit which records appear in a component. ### Basic Syntax ``` FieldApiName Operator Value ``` ### Common Operators | Operator | Description | Example | | -------- | ----------------------- | --------------------------------------------- | | = | Equals | Status = 'Active' | | != | Not Equals | Status != 'Closed' | | > | Greater Than | Amount > 10000 | | < | Less Than | Amount < 5000 | | >= | Greater Than or equal | CloseDate >= TODAY | | <= | Less Than or equal | CreatedDate <= LAST\_WEEK | | LIKE | Pattern matching | Name LIKE '%Acme%' | | IN | Match any value in list | Status IN ('Open','Pending') | | NOT IN | Not in list | StageName NOT IN ('Closed Won','Closed Lost') | ### Combining Conditions **AND - All conditions must be true:** ``` Status = 'Active' AND OwnerId = '{{User.Id}}' ``` **OR - Any condition must be true:** ``` Priority = 'High' OR Status = 'Escalated' ``` **Complex Combinations:** ``` (Status = 'Active' OR Status = 'Pending') AND OwnerId = '{{User.Id}}' ``` ### Date Filters **Relative Dates:** ``` CreatedDate = TODAY CreatedDate = YESTERDAY CreatedDate = THIS_WEEK CreatedDate = LAST_WEEK CreatedDate = THIS_MONTH CreatedDate = LAST_MONTH CreatedDate = THIS_YEAR ``` **Date Ranges:** ``` CreatedDate = LAST_N_DAYS:30 CloseDate = NEXT_N_DAYS:7 CreatedDate = LAST_N_MONTHS:3 ``` **Specific Dates:** ``` CreatedDate = 2024-01-15 CreatedDate >= 2024-01-01 ``` #### NULL Checks ``` Description != null // Has a value Email = null // Is empty ``` ### Dynamic Reference in Filters **Important:** Always wrap dynamic references in single quotes. ``` AccountId = '{{Record.Id}}' OwnerId = '{{User.Id}}' Department__c = '{{User.Department}}' ``` ### Common Filter Patterns **Related Records:** ``` AccountId = '{{Record.Id}}' WhatId = '{{Record.Id}}' ParentId = '{{Record.Id}}' ``` **User's Records:** ``` OwnerId = '{{User.Id}}' CreatedById = '{{User.Id}}' ManagerId = '{{User.Id}}' ``` **Exclude Closed Items:** ``` IsClosed = false Status != 'Closed' StageName NOT IN ('Closed Won','Closed Lost') ``` **Recent Records:** ``` CreatedDate = LAST_N_DAYS:30 LastModifiedDate = THIS_MONTH ActivityDate >= TODAY ``` **Need help with filters?** Check Troubleshooting & FAQs for common filter issues. *** ## Field Names Specifies which fields to display in comma-separated format (similar to SOQL SELECT clause). ### Syntax ``` FieldApiName1,FieldApiName2,FieldApiName3 ``` ### Examples **Contact Fields:** ``` Name,Email,Phone,Title ``` **Opportunity Fields:** ``` Name,StageName,Amount,CloseDate,Probability ``` **With Related Fields:** ``` Name,Account.Name,Owner.Name,Amount ``` ### Field Order Fields appear in the order specified: ``` Name,Email,Phone → Name | Email | Phone Phone,Name,Email → Phone | Name | Email ``` ### Best Practices * **Use readable order:** Put most important fields first * **Consider width:** Long field lists may cause horizontal scrolling * **Test on mobile:** Limit fields for mobile-friendly display * **Check permissions:** Users only see fields they can access *** ## Order By Specifies how records should be sorted (similar to SOQL ORDER BY clause). ### Syntax ``` FieldApiName [ASC|DESC] [NULLS FIRST|NULLS LAST] ``` ### Examples **Ascending (default):** ``` Name CreatedDate Amount ``` **Descending:** ``` CreatedDate DESC Amount DESC Priority__c DESC ``` **Multiple Fields:** ``` Priority__c DESC, Name ASC StageName, CloseDate DESC Status, LastModifiedDate DESC ``` ### Common Patterns **Alphabetical:** ``` Name LastName, FirstName ``` **Most Recent First:** ``` CreatedDate DESC LastModifiedDate DESC ActivityDate DESC ``` **Highest Value First:** ``` Amount DESC Quantity DESC Score__c DESC ``` **Priority-Based:** ``` Priority__c, Name Status, CreatedDate DESC ``` **Null Placement:** ``` CloseDate ASC NULLS LAST Amount DESC NULLS FIRST ``` *** ## Maximum Number of Records Controls the maximum number of records retrieved and displayed. ### Syntax ``` Maximum Number of Records: [number] ``` ### Examples ``` Maximum Number of Records: 50 Maximum Number of Records: 100 Maximum Number of Records: 200 ``` ### Purpose * **Performance optimization** - Fewer records = faster queries * **User experience** - Manageable amount of data to view * **Page load speed** - Improves initial rendering time ### Recommendations * **With Pagination:** Set based on per-page needs (e.g., `Maximum Number of Records: 100` with 20 items per page = 5 pages) * **Without Pagination:** Set based on user needs and performance (typically 50-100) * **For Metrics/Summaries:** Can be higher since only aggregated values display ### Combined with Pagination ``` Maximum Number of Records: 100 Show Pagination: On Number of Records per Page: 20 ``` Result: 100 records retrieved, displayed across 5 pages of 20 records each. *** ## Metric Aggregation Fields Shows aggregate values — totals, averages, counts — as summary metrics in the component header. ### Syntax ``` Function(FieldApiName) ``` Separate multiple metrics with commas: ``` SUM(Amount), COUNT(Id), AVG(Probability) ``` ### Supported Functions | Function | Returns | Metric Label | Example | | --------------- | ------------------------------------------- | ------------------------------------------------------------- | -------------------------- | | SUM | Total of a numeric field | Total \ | SUM(Amount) | | AVG | Average of a numeric field | Average \ | AVG(Probability) | | COUNT | Number of records with a value in the field | Count of \, or Record Count for an Id field | COUNT(Id) | | COUNT\_DISTINCT | Number of distinct values in the field | Unique Count of \ | COUNT\_DISTINCT(AccountId) | | MIN | Lowest value, or the earliest date | Minimum \, or Earliest \ for a date | MIN(CloseDate) | | MAX | Highest value, or the latest date | Maximum \, or Latest \ for a date | MAX(Amount) | ### Examples **Pipeline Summary:** ``` SUM(Amount), COUNT(Id), AVG(Probability) ``` **Case Load:** ``` COUNT(Id), COUNT_DISTINCT(AccountId), MAX(CreatedDate) ``` ### Availability Data Table, Kanban, List, and Map expose **Metric Aggregation Fields**. The Metric component is the single-metric alternative, configured from the property panel instead of an expression. ### Best Practices * **Match the function to the field type:** SUM and AVG need a numeric, currency, or percent field; COUNT, COUNT\_DISTINCT, MIN, and MAX also work on dates and text. * **Count records with an Id field:** `COUNT(Id)` is the record count, and its metric reads "Record Count". * **Check the expression form:** an entry that is not `Function(FieldApiName)` is ignored, so a typo makes the metric disappear instead of reporting an error. * **Keep it to a few metrics:** each expression runs its own aggregate query. * **COUNT\_DISTINCT on large objects:** it is the one function that cannot be computed in chunks, so on very large record sets its value can cover only part of the matching records. *** ## Header Properties Provide context and visual appeal to components. ### Header - Title **Syntax:** ``` Header - Title: [Text or Dynamic Reference] ``` **Examples:** ``` Header - Title: Related Opportunities Header - Title: {{User.FirstName}}'s Dashboard Header - Title: Opportunities for {{Record.Name}} ``` ### Header - Caption **Syntax:** ``` Header - Caption: [Text or Dynamic Reference] ``` **Examples:** ``` Header - Caption: Last 30 Days Header - Caption: Filtered by {{Record.Status}} Header - Caption: Team: {{User.Department}} ``` ### Header - Icon Name **Syntax:** ``` Header - Icon Name: [category:icon_name] ``` **Common Icons:** ``` standard:account standard:opportunity standard:case standard:contact standard:task standard:event utility:metrics utility:table utility:kanban ``` **Find Icons:** Browse the [Salesforce Lightning Design System Icons](https://www.lightningdesignsystem.com/icons/) *** ## Display Options Control how components appear on the page. ### Display as Card **Purpose:** Wraps component in a styled container **When to Use:** * Multiple components on same page need visual separation * Dashboard or summary views * Professional, polished appearance desired **Syntax:** ``` Display as Card: On ``` **Availability:** Not every component exposes this property — Data Table, Pivot Table, and Calendar don't have a Display as Card setting. ### Show Pagination **Purpose:** Breaks large datasets into pages **When to Use:** * More than 50-100 records * Improved initial load time needed * Better user navigation desired **Syntax:** ``` Show Pagination: On Number of Records per Page: 20 ``` ### Number of Records per Page **Purpose:** Controls records per page when pagination enabled **Common Values:** ``` 10 - Compact view 20 - Standard view 50 - Expanded view ``` *** ## Searchable and Filterable Fields Control which fields users can search or filter by. ### Search Fields Syntax ``` FieldName1,FieldName2,FieldName3 ``` **Example:** ``` Name,Email,Phone,Description ``` ### Filterable Fields Syntax ``` FieldName1,FieldName2,FieldName3 ``` **Example:** ``` Status,Priority,OwnerId,Type ``` ### Best Practices **For Search:** * Include text fields users would naturally search * Add key identifiers (names, codes, descriptions) * Consider email and phone for contact searches **For Filters:** * Include categorical fields (status, type, priority) * Add lookup fields (owner, account, related records) * Use fields with limited values for better UX *** ## Editable Fields Control which fields support inline editing. ### Syntax ``` FieldName1,FieldName2,FieldName3 ``` ### Examples **Opportunity Fields:** ``` StageName,CloseDate,Amount,Probability ``` **Case Fields:** ``` Status,Priority,OwnerId ``` **Task Fields:** ``` Status,Priority,ActivityDate ``` ### Requirements For inline editing to work: * User must have field-level Edit permission * User must have record-level Edit access * Field must be editable (not formula or roll-up) **Troubleshooting editing issues?** See [Troubleshooting & FAQs](/app-builder-components/resources/troubleshooting-and-faqs.md). *** ## Next Steps * [**Core Concepts**](/app-builder-components/getting-started/understanding-the-essentials/core-concepts.md) - Understand fundamental principles * [**Common Use Case Patterns**](/app-builder-components/getting-started/understanding-the-essentials/common-use-case-patterns.md) - See properties used in real scenarios * [**Troubleshooting & FAQs**](/app-builder-components/resources/troubleshooting-and-faqs.md) - Fix configuration problems --- # 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.avonnicomponents.com/app-builder-components/getting-started/understanding-the-essentials/component-properties-reference.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.