> 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/projects/use-cases/account-map-in-one-tag.md).
# Account map in one tag
## Overview
The account tree under the highlights panel: subsidiaries, their contacts, their open deals, one click to drill. One tag in your LWC, one nested query. The whole map is one **Relationship Graph** (`avonni-dd-relationship-graph`) on the Account record page, reading three levels of records through a query that carries its own children. This tutorial rebuilds the Northwind Distribution page of the Sales app in your own org.
## What you build
* Open Northwind Distribution and the map sits under the highlights panel. The account is the root label of the graph; **New contact** and **New opportunity** hang off it.
* **Accounts (3)** in the first column: Northwind Canada (Montréal), Northwind Iberia (Lisbon), Northwind Nordics (Stockholm), all Furniture retail, each with its city and industry under the name.
* Select Northwind Nordics and its **Contacts (2)** (Tomas Berg, CFO; Jonas Lindqvist, IT director) and **Opportunities (1)** (Nordics showroom refit, $126,500.00, Proposal) unfold to the right, the deal highlighted.
* **Add** on every group, a menu with **Open** on every card.
## Before you start
{% hint style="info" %}
**Adapt this to your own org.** This one runs on standard objects, so what to check is the shape of your data rather than a list of fields to create. The map is drawn from two lookups, `ParentId` on Account and `AccountId` on the children: if your subsidiaries hang off something else, point the root query and the `relationshipField` of each child at your own fields. The stage names on the cards are your own picklist values.
{% endhint %}
* The [Avonni LWC Components](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000FiERkUAN) package is installed, and the sales users hold a license and the package permission set. See [Installation & Licenses Management](https://docs.avonnicomponents.com/lwc-components/getting-started/installation-and-licenses-management).
* The Account record page of the app where the map goes. The examples below use Northwind Distribution, a furniture retailer, in the Sales app.
* Standard objects only. The graph reads these fields:
| Object | Field | Type | Role |
| ----------- | ------------------------- | ---------------------- | ------------------------------------------------------------ |
| Account | `Name` | Text | The card label |
| | `ParentId` | Lookup (Account) | Makes an account a subsidiary. The root query filters on it. |
| | `BillingCity`, `Industry` | Text, Picklist | The two facts under each subsidiary |
| Contact | `Name`, `AccountId` | Text, Lookup (Account) | The label and the link to the subsidiary |
| | `Title` | Text | The fact under each contact |
| Opportunity | `Name`, `AccountId` | Text, Lookup (Account) | The label and the link to the subsidiary |
| | `Amount`, `StageName` | Currency, Picklist | The two facts under each deal |
**Sample data.** One account, **Northwind Distribution** (Type Partner, Industry Furniture retail), and three accounts whose **Parent Account** is Northwind Distribution, each with its contacts and one open opportunity:
| Subsidiary | Billing City | Industry | Contacts (Title) | Opportunity (Amount, Stage, Close Date) |
| ----------------- | ------------ | ---------------- | ----------------------------------------------- | ------------------------------------------------------------ |
| Northwind Canada | Montréal | Furniture retail | Priya Nair (Store operations) | Spring catalog renewal (84,000, Negotiation, Oct 16, 2026) |
| Northwind Iberia | Lisbon | Furniture retail | Maya Chen (Procurement lead) | E-commerce integration (42,000, Qualification, Nov 20, 2026) |
| Northwind Nordics | Stockholm | Furniture retail | Tomas Berg (CFO), Jonas Lindqvist (IT director) | Nordics showroom refit (126,500, Proposal, Nov 6, 2026) |
Use the stage names of your org. The org in the figure had `Proposal` and `Negotiation` added to the Opportunity **Stage** picklist; a default org has `Proposal/Price Quote` and `Negotiation/Review` instead, and the cards show whichever value the record holds.
**Permissions.** The Avonni query follows Salesforce sharing and field-level security: a user sees the subsidiaries, contacts and deals they can read, and nothing else. Creating a contact or a deal from the root actions needs Create on those objects.
## Build it
{% stepper %}
{% step %}
### Create the records
1. Create **Northwind Distribution**, then the three subsidiaries with **Parent Account** set to it, then the four contacts and the three opportunities on the subsidiaries.
2. Check the hierarchy from the account: the standard **View Account Hierarchy** action lists the three children.
*Why:* the graph is drawn from `ParentId`, `AccountId` and nothing else. If the hierarchy is right, the map is right.
{% endstep %}
{% step %}
### Create the component and place the tag
Create a Lightning web component named `accountMap`. The template is one tag:
```html
```
`variant` stays on its default, `horizontal`, and `hide-items-count` on its default, off: the groups unfold to the right and carry their counts.
{% endstep %}
{% step %}
### Read the record id and write the nested query
On a record page the component receives the account id through `@api recordId`. Build the query from it once the component is connected:
```js
// accountMap.js
import { LightningElement, api, wire } from 'lwc';
import { getRecord, getFieldValue } from 'lightning/uiRecordApi';
import { NavigationMixin } from 'lightning/navigation';
import NAME_FIELD from '@salesforce/schema/Account.Name';
export default class AccountMap extends NavigationMixin(LightningElement) {
@api recordId;
query;
connectedCallback() {
this.query = {
objectApiName: 'Account',
filter: `ParentId = '${this.recordId}'`,
orderBy: 'Name ASC',
children: [
{ objectApiName: 'Contact', relationshipField: 'AccountId', orderBy: 'LastName ASC' },
{ objectApiName: 'Opportunity', relationshipField: 'AccountId', orderBy: 'Amount DESC' }
]
};
}
```
*Why:* the first level of the graph is the result of the root query. Querying the subsidiaries (`ParentId = `) puts them in the first column. Querying the account itself would add a level, **Accounts (1)**, holding one card that repeats the root label. Each child query names the lookup that points from the child to the parent level: `Contact.AccountId`, `Opportunity.AccountId`. `filter` is a SOQL WHERE clause without the keyword, `orderBy` a SOQL ORDER BY without the keyword.
{% endstep %}
{% step %}
### Map the three objects
```js
mapping = {
Account: { label: '{{Record.Name}}', name: '{{Record.Id}}', fields: ['BillingCity', 'Industry'] },
Contact: { label: '{{Record.Name}}', name: '{{Record.Id}}', fields: ['Title'] },
Opportunity: { label: '{{Record.Name}}', name: '{{Record.Id}}', fields: ['Amount', 'StageName'] }
};
```
*Why:* the mapping is keyed by object API name, one entry per level, and `fields` lists what shows under the card label. `name` set to the record id is what makes the item actions useful: the event carries it back as `targetName`.
{% endstep %}
{% step %}
### Label the root and add the actions
```js
@wire(getRecord, { recordId: '$recordId', fields: [NAME_FIELD] })
account;
get accountName() {
return this.account.data ? getFieldValue(this.account.data, NAME_FIELD) : '';
}
avatarAttributes = { fallbackIconName: 'standard:account' };
actions = [
{ name: 'newContact', label: 'New contact' },
{ name: 'newOpp', label: 'New opportunity' }
];
groupActions = [{ name: 'add', label: 'Add', iconName: 'utility:add' }];
itemActions = [{ name: 'open', label: 'Open', iconName: 'utility:open' }];
```
*Why:* the root of the graph is the record the page is on, so its `label` is read from the record rather than typed. `actions` sit under the root, `group-actions` in the header of every group, `item-actions` in the menu of every card.
{% endstep %}
{% step %}
### Handle the events
```js
handleAction(event) {
const objectApiName = event.detail.name === 'newContact' ? 'Contact' : 'Opportunity';
this[NavigationMixin.Navigate]({
type: 'standard__objectPage',
attributes: { objectApiName, actionName: 'new' },
state: { defaultFieldValues: `AccountId=${this.recordId}` }
});
}
handleGroupAction(event) {
const { name, targetName } = event.detail;
// 'add': open your own create form. targetName is the group's internal name.
}
handleItemAction(event) {
if (event.detail.name === 'open') {
this[NavigationMixin.Navigate]({
type: 'standard__recordPage',
attributes: { recordId: event.detail.targetName, actionName: 'view' }
});
}
}
}
```
*Why:* the component draws and the code decides. `actionclick` carries the action `name`; `itemactionclick` carries the `name` and the item's `targetName`, which is the record id set in the mapping, so **Open** is a navigation call. `groupactionclick` carries the group's internal name, not the object name, so a group action works best when it means the same thing on every group.
{% endstep %}
{% step %}
### Expose the component and place it on the record page
1. In `accountMap.js-meta.xml`, expose the component for record pages of Account:
```xml
66.0
true
Account Map
lightning__RecordPage
```
2. Deploy, open Northwind Distribution, then **Edit Page** in **Lightning App Builder**. Drag **Account Map** into the main region under the highlights panel and **Save**, then **Activate** the page for the Sales app.
*Why:* the figure uses a page with the highlights panel and the map, no **Details** tab and no sidebar, so the three columns of the graph have the full width.
{% endstep %}
{% endstepper %}
## The settings that matter
| Setting | Value | Why |
| ------------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `query.filter` | `ParentId = ''` | The root of the graph is the query result. Aiming at the children puts the subsidiaries in the first column, with no extra level repeating the account. |
| `query.children[].relationshipField` | `AccountId` on Contact and on Opportunity | The lookup from the child level to the parent level. That one field is the whole join. |
| `mapping.