StoreConnect POS customization
Use the supported POS configuration and extension surfaces documented for the
installed StoreConnect release. Release contracts vary, so resolve the exact
objects, fields, values, and capabilities from current StoreConnect
documentation and the live Salesforce schema rather than from copied examples
or application internals.
Use storeconnect-pos-setup for operational setup such as outlets, registers,
operator access, payment configuration, fulfillment, hardware, and
synchronization health. Use this skill for supported changes to POS appearance
and behavior.
Pick the extension point first
| You want to |
Use |
Safeguard |
| Change which fields a supported screen shows or their order |
Layout configuration |
Prefer this smallest, lowest-risk option. |
| Let an operator narrow a list |
Layout filter configuration |
Treat it as presentation, never authorization. |
| Change initial sorting or filtering |
Supported layout settings |
Verify behavior and scale on the installed release. |
| Render supported custom content |
A POS view |
Use only the documented context and data surface. |
| Add a button, menu entry, or tile |
A supported action configuration |
Confirm the action, parameters, permissions, and offline behavior in current documentation. |
| Add supported cross-screen styling or scripting |
Script or style configuration |
Keep it minimal, reversible, and within documented extension points. |
| Produce a receipt, docket, document, or label |
A supported print template |
Select the documented output family before authoring and test it safely. |
Choose the first supported option that meets the outcome. Avoid broad scripting
when configuration or a view is sufficient.
Routing — read the reference that matches the task
Open only the reference needed for the requested outcome:
- Layouts, fields, filters, views, or supported data contexts →
references/layouts-and-views.md. Resolve
release-specific contracts from current documentation and the live schema.
- Buttons, menus, tiles, or action sequences →
references/actions-reference.md. Confirm
every action and parameter against the current installed release.
- Receipts, dockets, documents, or labels →
references/print-templates.md. Select and
validate the supported output family before rollout.
- Supported scripts, styles, or integrations →
references/js-and-integration-patterns.md.
Do not target undocumented application structure.
- Performance, testing, offline behavior, rollout, or rollback →
references/performance-and-rollout.md.
Non-negotiable safety rules
Never embed secrets in client-visible customization. Assume POS views,
scripts, styles, and print output can be inspected on the register. Keep
credentials and privileged operations in an approved server-side integration,
and use obvious placeholders in documentation and examples.
Treat every rendered value as untrusted. Apply the current documented
escaping and encoding rules for its output context. Never place operator,
customer, scanned, or externally supplied content into an executable context.
Never log, transmit, or print unnecessary customer or payment data. Keep
diagnostics sanitized and limited to what support needs. Do not include
credentials, payment authorization values, personal data, or full transaction
content.
Treat price changes and discounts as privileged outcomes. Use the
documented permission-enforced workflow, require explicit business approval,
and verify that the result is auditable. Hidden controls and client-side checks
are usability aids, not authorization.
Test away from live trading and know the rollback first. Capture the
existing configuration, use a non-production or non-trading register where
possible, and keep a tested path back to the previous supported configuration.
Do not remove a referenced customization until its dependants have been
identified and safely redirected.
Preserve supported offline operation. A customization must remain usable,
or degrade clearly and safely, when connectivity is unavailable. Never make a
required sales or payment outcome depend on an optional external service.
Workflow
- Confirm the environment, intended register scope, business owner, and whether
the target is in production.
- Select the smallest supported extension point, then read its matching
reference and current StoreConnect documentation.
- Inspect the live Salesforce schema and current configuration. Do not infer a
release contract from another store, old examples, or application code.
- Record the existing configuration and define the rollback before editing.
- Make the smallest additive change. Use a distinct custom identifier and do
not replace a shipped surface without explicit approval and an inventory of
the displaced behavior.
- Verify all release-specific names, values, permissions, and supported
contexts against current documentation and live metadata.
- Allow synchronization to complete, then test the intended outcome, empty and
long-content states, restricted operators, supported screen sizes, offline
behavior, and the rollback.
- Review sanitized supported diagnostics and confirm that core trading,
navigation, payment, printing, and recovery outcomes still work.
How a change reaches a register, and how to verify
StoreConnect and Salesforce synchronize asynchronously; wait, re-read and never repeat a write merely because it is not visible yet.
After the supported synchronization workflow completes, verify the change on
the intended register. If it is not visible, re-read the Salesforce
configuration, check supported synchronization health, and follow the current
StoreConnect troubleshooting procedure. Do not repeat writes or use a
potentially disruptive recovery operation without first protecting unsaved work
and obtaining the required approval.
Failure modes that produce no error
| Symptom |
Check |
| A control does nothing |
Confirm the action, parameters, required context, and operator permissions against current documentation. |
| A control ignores configuration |
Confirm that its names and values match the installed release contract. |
| A custom view is blank |
Validate its syntax, supported context, and available data using current documentation and sanitized diagnostics. |
| A value is missing |
Confirm the field exists in the live schema and is available to that supported view context. |
| A script or style works only on some screens |
Confirm that the extension point is supported on every intended surface and release. |
| A global customization has no effect |
Re-read its required activation, scope, and channel configuration in current documentation. |
| Print output is blank or malformed |
Confirm the selected output family, template syntax, data context, and target printer configuration. |
| Sorting or filtering appears ignored |
Re-read the live layout configuration and verify it against the current release contract. |
Related skills
storeconnect-pos-setup — operational POS setup, access, hardware, and
synchronization health.storeconnect-salesforce-data — authorized inspection and editing of
StoreConnect configuration in Salesforce.storeconnect-liquid — storefront Liquid syntax only. Do not assume its
data surfaces or runtime behavior are available in POS.
1---2name: storeconnect-pos-customization-23description: Customize StoreConnect POS through supported layouts, filters, views, actions, scripts, styles, and print templates. Use when changing what a POS screen, list, cart, button, menu, modal, receipt, docket, or label shows or does, or when reviewing a POS customization for safety, performance, offline behavior, testing, and rollout.4---56# StoreConnect POS customization78Use the supported POS configuration and extension surfaces documented for the9installed StoreConnect release. Release contracts vary, so resolve the exact10objects, fields, values, and capabilities from current StoreConnect11documentation and the live Salesforce schema rather than from copied examples12or application internals.1314Use `storeconnect-pos-setup` for operational setup such as outlets, registers,15operator access, payment configuration, fulfillment, hardware, and16synchronization health. Use this skill for supported changes to POS appearance17and behavior.1819## Pick the extension point first2021| You want to | Use | Safeguard |22|---|---|---|23| Change which fields a supported screen shows or their order | Layout configuration | Prefer this smallest, lowest-risk option. |24| Let an operator narrow a list | Layout filter configuration | Treat it as presentation, never authorization. |25| Change initial sorting or filtering | Supported layout settings | Verify behavior and scale on the installed release. |26| Render supported custom content | A POS view | Use only the documented context and data surface. |27| Add a button, menu entry, or tile | A supported action configuration | Confirm the action, parameters, permissions, and offline behavior in current documentation. |28| Add supported cross-screen styling or scripting | Script or style configuration | Keep it minimal, reversible, and within documented extension points. |29| Produce a receipt, docket, document, or label | A supported print template | Select the documented output family before authoring and test it safely. |3031Choose the first supported option that meets the outcome. Avoid broad scripting32when configuration or a view is sufficient.3334## Routing — read the reference that matches the task3536Open only the reference needed for the requested outcome:3738- **Layouts, fields, filters, views, or supported data contexts** →39 [references/layouts-and-views.md](references/layouts-and-views.md). Resolve40 release-specific contracts from current documentation and the live schema.41- **Buttons, menus, tiles, or action sequences** →42 [references/actions-reference.md](references/actions-reference.md). Confirm43 every action and parameter against the current installed release.44- **Receipts, dockets, documents, or labels** →45 [references/print-templates.md](references/print-templates.md). Select and46 validate the supported output family before rollout.47- **Supported scripts, styles, or integrations** →48 [references/js-and-integration-patterns.md](references/js-and-integration-patterns.md).49 Do not target undocumented application structure.50- **Performance, testing, offline behavior, rollout, or rollback** →51 [references/performance-and-rollout.md](references/performance-and-rollout.md).5253## Non-negotiable safety rules5455**Never embed secrets in client-visible customization.** Assume POS views,56scripts, styles, and print output can be inspected on the register. Keep57credentials and privileged operations in an approved server-side integration,58and use obvious placeholders in documentation and examples.5960**Treat every rendered value as untrusted.** Apply the current documented61escaping and encoding rules for its output context. Never place operator,62customer, scanned, or externally supplied content into an executable context.6364**Never log, transmit, or print unnecessary customer or payment data.** Keep65diagnostics sanitized and limited to what support needs. Do not include66credentials, payment authorization values, personal data, or full transaction67content.6869**Treat price changes and discounts as privileged outcomes.** Use the70documented permission-enforced workflow, require explicit business approval,71and verify that the result is auditable. Hidden controls and client-side checks72are usability aids, not authorization.7374**Test away from live trading and know the rollback first.** Capture the75existing configuration, use a non-production or non-trading register where76possible, and keep a tested path back to the previous supported configuration.77Do not remove a referenced customization until its dependants have been78identified and safely redirected.7980**Preserve supported offline operation.** A customization must remain usable,81or degrade clearly and safely, when connectivity is unavailable. Never make a82required sales or payment outcome depend on an optional external service.8384## Workflow85861. Confirm the environment, intended register scope, business owner, and whether87 the target is in production.882. Select the smallest supported extension point, then read its matching89 reference and current StoreConnect documentation.903. Inspect the live Salesforce schema and current configuration. Do not infer a91 release contract from another store, old examples, or application code.924. Record the existing configuration and define the rollback before editing.935. Make the smallest additive change. Use a distinct custom identifier and do94 not replace a shipped surface without explicit approval and an inventory of95 the displaced behavior.966. Verify all release-specific names, values, permissions, and supported97 contexts against current documentation and live metadata.987. Allow synchronization to complete, then test the intended outcome, empty and99 long-content states, restricted operators, supported screen sizes, offline100 behavior, and the rollback.1018. Review sanitized supported diagnostics and confirm that core trading,102 navigation, payment, printing, and recovery outcomes still work.103104## How a change reaches a register, and how to verify105106StoreConnect and Salesforce synchronize asynchronously; wait, re-read and never repeat a write merely because it is not visible yet.107108After the supported synchronization workflow completes, verify the change on109the intended register. If it is not visible, re-read the Salesforce110configuration, check supported synchronization health, and follow the current111StoreConnect troubleshooting procedure. Do not repeat writes or use a112potentially disruptive recovery operation without first protecting unsaved work113and obtaining the required approval.114115## Failure modes that produce no error116117| Symptom | Check |118|---|---|119| A control does nothing | Confirm the action, parameters, required context, and operator permissions against current documentation. |120| A control ignores configuration | Confirm that its names and values match the installed release contract. |121| A custom view is blank | Validate its syntax, supported context, and available data using current documentation and sanitized diagnostics. |122| A value is missing | Confirm the field exists in the live schema and is available to that supported view context. |123| A script or style works only on some screens | Confirm that the extension point is supported on every intended surface and release. |124| A global customization has no effect | Re-read its required activation, scope, and channel configuration in current documentation. |125| Print output is blank or malformed | Confirm the selected output family, template syntax, data context, and target printer configuration. |126| Sorting or filtering appears ignored | Re-read the live layout configuration and verify it against the current release contract. |127128## Related skills129130- `storeconnect-pos-setup` — operational POS setup, access, hardware, and131 synchronization health.132- `storeconnect-salesforce-data` — authorized inspection and editing of133 StoreConnect configuration in Salesforce.134- `storeconnect-liquid` — storefront Liquid syntax only. Do not assume its135 data surfaces or runtime behavior are available in POS.
GetStoreConnect