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-customization3description: 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<!-- Generated from shared/skills. Do not edit this copy. -->78# StoreConnect POS customization910Use the supported POS configuration and extension surfaces documented for the11installed StoreConnect release. Release contracts vary, so resolve the exact12objects, fields, values, and capabilities from current StoreConnect13documentation and the live Salesforce schema rather than from copied examples14or application internals.1516Use `storeconnect-pos-setup` for operational setup such as outlets, registers,17operator access, payment configuration, fulfillment, hardware, and18synchronization health. Use this skill for supported changes to POS appearance19and behavior.2021## Pick the extension point first2223| You want to | Use | Safeguard |24|---|---|---|25| Change which fields a supported screen shows or their order | Layout configuration | Prefer this smallest, lowest-risk option. |26| Let an operator narrow a list | Layout filter configuration | Treat it as presentation, never authorization. |27| Change initial sorting or filtering | Supported layout settings | Verify behavior and scale on the installed release. |28| Render supported custom content | A POS view | Use only the documented context and data surface. |29| Add a button, menu entry, or tile | A supported action configuration | Confirm the action, parameters, permissions, and offline behavior in current documentation. |30| Add supported cross-screen styling or scripting | Script or style configuration | Keep it minimal, reversible, and within documented extension points. |31| Produce a receipt, docket, document, or label | A supported print template | Select the documented output family before authoring and test it safely. |3233Choose the first supported option that meets the outcome. Avoid broad scripting34when configuration or a view is sufficient.3536## Routing — read the reference that matches the task3738Open only the reference needed for the requested outcome:3940- **Layouts, fields, filters, views, or supported data contexts** →41 [references/layouts-and-views.md](references/layouts-and-views.md). Resolve42 release-specific contracts from current documentation and the live schema.43- **Buttons, menus, tiles, or action sequences** →44 [references/actions-reference.md](references/actions-reference.md). Confirm45 every action and parameter against the current installed release.46- **Receipts, dockets, documents, or labels** →47 [references/print-templates.md](references/print-templates.md). Select and48 validate the supported output family before rollout.49- **Supported scripts, styles, or integrations** →50 [references/js-and-integration-patterns.md](references/js-and-integration-patterns.md).51 Do not target undocumented application structure.52- **Performance, testing, offline behavior, rollout, or rollback** →53 [references/performance-and-rollout.md](references/performance-and-rollout.md).5455## Non-negotiable safety rules5657**Never embed secrets in client-visible customization.** Assume POS views,58scripts, styles, and print output can be inspected on the register. Keep59credentials and privileged operations in an approved server-side integration,60and use obvious placeholders in documentation and examples.6162**Treat every rendered value as untrusted.** Apply the current documented63escaping and encoding rules for its output context. Never place operator,64customer, scanned, or externally supplied content into an executable context.6566**Never log, transmit, or print unnecessary customer or payment data.** Keep67diagnostics sanitized and limited to what support needs. Do not include68credentials, payment authorization values, personal data, or full transaction69content.7071**Treat price changes and discounts as privileged outcomes.** Use the72documented permission-enforced workflow, require explicit business approval,73and verify that the result is auditable. Hidden controls and client-side checks74are usability aids, not authorization.7576**Test away from live trading and know the rollback first.** Capture the77existing configuration, use a non-production or non-trading register where78possible, and keep a tested path back to the previous supported configuration.79Do not remove a referenced customization until its dependants have been80identified and safely redirected.8182**Preserve supported offline operation.** A customization must remain usable,83or degrade clearly and safely, when connectivity is unavailable. Never make a84required sales or payment outcome depend on an optional external service.8586## Workflow87881. Confirm the environment, intended register scope, business owner, and whether89 the target is in production.902. Select the smallest supported extension point, then read its matching91 reference and current StoreConnect documentation.923. Inspect the live Salesforce schema and current configuration. Do not infer a93 release contract from another store, old examples, or application code.944. Record the existing configuration and define the rollback before editing.955. Make the smallest additive change. Use a distinct custom identifier and do96 not replace a shipped surface without explicit approval and an inventory of97 the displaced behavior.986. Verify all release-specific names, values, permissions, and supported99 contexts against current documentation and live metadata.1007. Allow synchronization to complete, then test the intended outcome, empty and101 long-content states, restricted operators, supported screen sizes, offline102 behavior, and the rollback.1038. Review sanitized supported diagnostics and confirm that core trading,104 navigation, payment, printing, and recovery outcomes still work.105106## How a change reaches a register, and how to verify107108StoreConnect and Salesforce synchronize asynchronously; wait, re-read and never repeat a write merely because it is not visible yet.109110After the supported synchronization workflow completes, verify the change on111the intended register. If it is not visible, re-read the Salesforce112configuration, check supported synchronization health, and follow the current113StoreConnect troubleshooting procedure. Do not repeat writes or use a114potentially disruptive recovery operation without first protecting unsaved work115and obtaining the required approval.116117## Failure modes that produce no error118119| Symptom | Check |120|---|---|121| A control does nothing | Confirm the action, parameters, required context, and operator permissions against current documentation. |122| A control ignores configuration | Confirm that its names and values match the installed release contract. |123| A custom view is blank | Validate its syntax, supported context, and available data using current documentation and sanitized diagnostics. |124| A value is missing | Confirm the field exists in the live schema and is available to that supported view context. |125| A script or style works only on some screens | Confirm that the extension point is supported on every intended surface and release. |126| A global customization has no effect | Re-read its required activation, scope, and channel configuration in current documentation. |127| Print output is blank or malformed | Confirm the selected output family, template syntax, data context, and target printer configuration. |128| Sorting or filtering appears ignored | Re-read the live layout configuration and verify it against the current release contract. |129130## Related skills131132- `storeconnect-pos-setup` — operational POS setup, access, hardware, and133 synchronization health.134- `storeconnect-salesforce-data` — authorized inspection and editing of135 StoreConnect configuration in Salesforce.136- `storeconnect-liquid` — storefront Liquid syntax only. Do not assume its137 data surfaces or runtime behavior are available in POS.
GetStoreConnect