> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/guide-working-with-mango.md).

# Guide: Working with Mango

### Overview

**Mango** is the mongoose who lives inside PeakCommerce — an AI assistant you can ask questions in plain language, and hand real build work to. She is not a search box with a personality: she reads **your own tenant's configuration** when she answers, and she **builds** components, pages, and rules from a description.

**Where she lives:** Mango is part of the **PeakCommerce admin app**. She is not on this help center — the search box here is GitBook's own documentation search (its **AI Answer** option answers from these published pages), which is a different thing and knows nothing about your tenant. To ask Mango anything, open her in the app.

|                         | **This help center**               | **Mango, in the admin app**                                    |
| ----------------------- | ---------------------------------- | -------------------------------------------------------------- |
| What answers you        | GitBook search + its **AI Answer** | Mango                                                          |
| What it reads           | These published pages              | Your live catalog, journeys, and analytics                     |
| Good for                | *"How do commerce actions work?"*  | *"Why does **our** cancellation journey skip the offer step?"* |
| Can it change anything? | No                                 | No — she **proposes**, you approve                             |

This guide covers Mango in the app: how to open her, what she can actually see and do, how the propose-and-approve build flow works, what she deliberately cannot do, and when to hand off to a human.

### 1. Open Mango in the admin app

Mango is on call from every page of the admin app — including the full-screen editors — so you never have to leave what you're doing to ask something.

1. Open the **user menu** (your name, bottom-left) and click **Support**.
2. The **Support dialog** opens, and it knows what page you're on: it suggests questions relevant to that screen. Pick one, type your own, or start a **voice session** — Mango holds a natural spoken conversation as easily as a typed one. Your question opens the conversation already sent, so you never retype it.
3. The conversation lives in the bottom-right corner while you work. **Collapse** it and a small **Mango chip** keeps your place so you can pick the thread back up; **close** it and the corner is yours again — Mango only appears when you ask for her.
4. Change the conversation **language** from the flag control at the top of the panel. Mango converses in English, Deutsch, Español, Français, Italiano, 日本語, Nederlands, Polski, Português, Türkçe, and 中文 — in both chat and voice.

If Mango can't hold a conversation right now, the Support dialog says so plainly, keeps the routes to this help center and to <support@peakcommerce.com>, and re-checks on its own so she returns without a reload.

### 2. Ask about your own configuration

This is the part that makes the in-app Mango different from generic documentation chat. She answers from a small set of **read-only lookups** into your tenant. Here's what each one covers and the kind of question it settles.

**Your catalog and plan pricing.** Products, plans, charges, and what each plan actually costs. Ask *"what does the annual tier of our Advanced plan cost?"* or *"which plans include the onboarding charge?"* and you get your numbers, not an example from a manual.

**Your journeys.** A **journey** is the multi-step flow a customer walks through — signup, checkout, cancellation, win-back. Mango can list the journeys in your tenant, and for any one of them read its full configuration:

* **Steps** — in order, with each step's label, role, whether it's **terminal** (ends the journey) and whether it **resolves an outcome**.
* **Routing** — the branching variable on a step and where each value sends the customer, so *"why does our cancellation flow skip the offer step?"* has a traceable answer.
* **Commerce actions** — the operations a step performs (create an order, apply a discount, cancel a subscription), in execution order, including which ones are **committing** and which are conditional.
* **Field mappings** — the values each commerce action sends. This matters when you want to *change* something: a **literal** mapping holds the value itself and is edited on the action (**Content → Journeys → your journey → Edit → Steps → the step → the action → Edit action**); anything else is fed from earlier in the journey by a **context key**, so it's changed where that value is produced, not on the action. Mango will tell you which kind you're looking at. Credential-shaped values come back `[redacted]` on purpose — she points you at the action rather than reading a secret out loud.

**Recent journey activity, in aggregate.** Session counts and where sessions are sitting in the flow — useful for *"are people getting past step 3 since we changed it?"*. Customer identity and captured form data are deliberately **not** visible to Mango; for an individual-customer investigation she'll send you to that journey's session view in the app.

**Retention analytics.** Cancellation reasons and save rates, computed from the same source as the app's **Retention** analytics tab — so her figures can never disagree with the dashboard you're looking at.

### 3. Build with Mango — the propose-and-approve flow

Mango's second job is building. The pattern is the same everywhere: **you describe, she drafts, you accept or reject.** Nothing she writes goes live on its own.

**Where you'll see it:**

* **Content → Component Library** — **Create with Mango** to generate a new component from a description, or **Open with Mango** on one that already exists.
* **The component editor** — the **Chat** rail, alongside **Insert** (ready-made snippets) and **Fields** (the editable properties page authors will see).
* **The page editor** — the agent rail, for assembling or changing a page from your components.
* **The rule engines** — **Business Rules**, **Pricing Rules**, **Territory Rules**, and **Policies** each carry their own **Create with Mango** button.

**How a build actually goes**, using a pricing block as the example:

1. In **Content → Component Library**, click **Create with Mango** and describe it: *"a three-tier pricing table with a highlighted middle plan."*
2. Mango generates a working component — the **code**, the **layout**, and the **fields** (the properties a page author will be able to edit without touching code).
3. Refine it in **Chat**: *"make the middle card violet and add a billing-period toggle."* She **proposes** the edit — **Accept** applies it and the code, fields, and preview all move together; **Reject** discards it. Every accepted change is recorded, so your team can see who changed what and when.
4. Set the component's **context** (Checkout, Storefront, Payment, or Portal) — a component only appears in editors whose context matches, which is why a new block sometimes seems "missing" from a page editor.
5. Drop it on a page in **Content → Pages**, give the page a **slug** (its public path, e.g. `/s/plans`), **publish** it, and bind it to a journey step to put it in a live flow. See [Designing Pages with the Editor and Mango](/guides/feature-guides/build-and-launch/guide-designing-pages-with-mango.md) for the full page walkthrough.

Rules follow the same shape: describe the behavior (*"15% off annual upgrades"*), Mango drafts the rule, and you review and activate it. The draft is a starting point you own — read the conditions before you turn it on.

### 4. What Mango will not do

Knowing the boundaries is what makes her safe to ask anything:

* **Her knowledge tools are strictly read-only.** She can explain and diagnose your catalog, journeys, and rules; she cannot change them. At worst a confused question produces a wrong answer — never a wrong action.
* **She proposes, you approve.** Generated components, pages, and rules are drafts you accept or reject. She never applies an edit silently.
* **No customer PII.** Identities and captured form data are kept out of her view by design.
* **No account or billing operations.** She won't issue refunds, cancel a subscription, or change a customer's plan — those stay with you, the CSR tools, and the portals.
* **Secrets stay secret.** Credential-shaped configuration values are redacted in what she reads back.

Every conversation is tied to your organization and your user, so if you escalate afterwards the support team already has the context.

### 5. Getting a better answer

* **Name the thing.** *"Our Win-Back journey"* beats *"the journey"* — if the name is ambiguous she'll ask which one you meant, and naming it up front saves a round trip.
* **Ask "why", not just "what".** She reads routing and commerce actions, so *"why does this step run twice?"* is answerable in a way a documentation search isn't.
* **Ask for the path.** *"Where do I change that?"* gets you the click path in the app, not just an explanation.
* **Check figures against the screen.** Her catalog and retention numbers come from the same source as the app's own screens — if something looks off, that's worth reporting, not working around.
* **If she's wrong, tell us.** A wrong answer is a documentation or configuration gap we want to close — email <support@peakcommerce.com> with the question you asked.

### 6. When to bring in a human

Mango is the fastest first stop, not the only one. Go to the team when you need an individual customer's records, a change to your Zuora or Salesforce integration, an account or contractual question, or anything urgent:

* **Email** — <support@peakcommerce.com>.
* **Slack** — most customers have a shared channel our customer success team watches.

Full details on priorities and response times are in [Contact Support](https://docs.peakcommerce.com/support/support-processes/contact-support).

### Related

* [Meet Mango](https://docs.peakcommerce.com/product/getting-started/meet-mango) — who she is and where she came from.
* [Getting Help from Mango](https://docs.peakcommerce.com/support/getting-help-from-mango) — every route to help, from quickest to most personal.
* [Designing Pages with the Editor and Mango](/guides/feature-guides/build-and-launch/guide-designing-pages-with-mango.md) — the full page-and-component walkthrough.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/guides/guide-working-with-mango.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.