> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/crm-and-fidelity/comarch/data-mapping.md).
# Data mapping
Comarch mapping decides which loyalty data becomes visible on the pass. This page lists the fields exposed by the connector and explains when they are available.
Real-world examples
* A loyalty card shows points, tier, and member number from Comarch.
* A store card shows the preferred store captured during enrolment.
* A clienteling pass shows customer profile data and store context together.
## Customer fields
The connector reads customer data from the Comarch CLM `profile/customers` API.
The fields below are available to the pass by default.
| Wallet field | Comarch source | Notes |
| --------------------------------------- | ---------------------------- | ------------------------------------------------------------ |
| `firstName` | Customer first name | Standard customer field |
| `lastName` | Customer last name | Standard customer field |
| `email` | Login or address email | Uses the email found in the profile |
| `phoneNumber` | Mobile or phone from address | Uses the phone found in the profile |
| `comarch.customer.loyaltyPointsBalance` | Main points balance | Available by default |
| `comarch.customer.mainIdentifier` | Primary loyalty card number | Useful for visible member numbers |
| `comarch.customer.statusName` | Membership status label | Often used for tier display |
| `comarch.customer.waitingToBookPoints` | Pending points balance | Available only when transaction balance retrieval is enabled |
The full customer payload is also available under `debug.comarch.customer`.
## Pending points option
By default, the connector reads the main points balance only.
Enable **Retrieve customer transaction balance** when pending points are also needed. This adds an extra Comarch API call during refresh.
## Store fields
Store data is fetched only when the pass or enrolment flow provides `storeId`.
The connector then reads the matching location from the Comarch partner API.
| Wallet field | Comarch source | Notes |
| -------------------------- | -------------- | ------------------------------------ |
| `comarch.store.code` | Location code | Usually the original `storeId` value |
| `comarch.store.name` | Location name | Store display name |
| `comarch.store.address` | Street | Main street address |
| `comarch.store.city` | City | Store city |
| `comarch.store.postalCode` | Postal code | Store postal code |
| `comarch.store.country` | Country | Store country |
| `comarch.store.latitude` | GPS latitude | Optional location coordinate |
| `comarch.store.longitude` | GPS longitude | Optional location coordinate |
The full store payload is also available under `debug.comarch.store`.
## Use the fields in a pass template
Set the pass template **Customer provider** to `comarch.customer`.
Set the **Store provider** to `comarch.store` when store data is needed.
Typical template expressions include:
* `{{ comarch.customer.loyaltyPointsBalance }}`
* `{{ comarch.customer.statusName }}`
* `{{ comarch.store.name }}`
## Customize the mapping
The default mapping covers the most common loyalty and store use cases.
When a project needs a different field structure, extra fields, or custom transformation logic, the mapping can be adapted through extensibility.
This makes it possible to reshape Comarch data before it is exposed to the pass.
See [Extensibility](/connectors/crm-and-fidelity/comarch/extensibility.md) for the customization model.
## Mapping notes
Keep the first pass version simple.
Most projects start with member number, points, tier, and one store field. Extra fields can follow once the base refresh path is validated.
## FAQ
Can the default Comarch mapping be customized?
Yes. The default mapping can be adapted through extensibility when a project needs custom fields, renamed fields, or specific transformation rules.
See [Extensibility](/connectors/crm-and-fidelity/comarch/extensibility.md) for the implementation approach.
Are all Comarch fields exposed by default?
No. This page lists the default fields exposed by the connector.
Additional fields can be added when the Comarch payload contains them and the project mapping is extended accordingly.
When is store data available on the pass?
Store data is available only when a `storeId` is provided in the pass or enrolment flow.
Without that value, the connector does not run the store lookup.
---
# 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.thewalletcrew.io/connectors/crm-and-fidelity/comarch/data-mapping.md?ask=&goal=
```
`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.