Documentation

Events

Elevate, May 20-22-2025, Miami Beach, Florida

Use a custom event to communicate the status of a specific process.

You can use a custom window event that the federated component sends to communicate the status of a specific process. This event helps the host application understand the result of operations handled by the component. You can use the event to trigger UI changes, update logs, or perform other actions based on the process status.

Make sure your host application is properly set up to listen for window events.

mistStatus

mistStatus is a generic custom window event that you can use to track various processes in the InStore product modules.

mistStatus event details

The mistStatus event includes the following properties in its detail object:
  • process (String): specifies the process that triggered the event. The value can be one of the following:
    • checkout
    • refund
    • deviceregistration
    • cashmanagement
  • status (String): indicates the outcome of the process. The value can be one of the following:
    • success: the process completed successfully.
    • cancelled: the process was cancelled by the user or system.
    • error: an error occurred during the process.
    • activated: the process was successfully activated.
  • message (String): a description of the error, only present when the status is error. This property provides additional context about the failure. Use try...catch blocks, where necessary, to handle potential errors when processing event details.

inStoreCore-Alert

inStoreCore-Alert is a custom window event that can trigger responses based on process steps that occur in the InStore colleague app; for example, to display toast messages. This event is available for use in modular_store.

inStoreCore-Alert event details

The inStoreCore-Alert event includes the following properties in its detail object:
  • message (String): specifies text to be displayed if the event is triggered. This is any localized string that the retailer specifies. For example, "Connected to card processor," "Requesting user input," and "Authorizing card." Sample base messages are stored in InStore language bundles, or you can pull strings from an external source.
  • properties: unsupported.
  • severity (String): indicates the outcome of the process. Its value can be any one of the following:
    • success: the process completed successfully.
    • info: information is provided about the process.
    • warning: the process completed with a warning.
    • error: an error occurred during the process.

inStoreCore-receiptChoice

inStoreCore-receiptChoice is a custom window event that can generate a receipt by using the method that a user selected in the InStore colleague app. The methods are activated in the InStore colleague app by using any one of the following items:

inStoreCore-receiptChoice event details

The inStoreCore-receiptChoice event includes the following properties in its detail object:
  • choice (list): specifies the receipt delivery methods requested by a user. This is an array that can contain a maximum of four strings, which can be any of the following values:
    • Paper: the receipt is intended for the printer that is assigned to the current workstation.
    • Email: the receipt is intended for the email address contained in the cart.
    • Text: the receipt is intended for the text number contained in the cart.
    • None: no receipt is generated. This option overrides any other option(s) selected.

inStoreCore-screenChange

inStoreCore-screenChange is a custom window event that can record a user's path through the colleague app.

inStoreCore-screenChange event details

The inStoreCore-screenChange event includes the following properties in its detail object:
  • screen (String): activates a listing of the pages that the user has traversed. For more information, see the list of pages.

Pages tracked by the inStoreCore-screenChange event

You can set up a listener for the inStoreCore-screenChange event to track user navigation through the following pages of the InStore colleague app:

Payments

  • CancelPayment
  • CashCollection
  • CashDrawerPrompt
  • ChangeDue
  • CreditProcessing
  • Exit
  • GiftCardEntry
  • GiftCardProcessing
  • PaymentEntry
  • POAConfirmation
  • PayByLinkEntry
  • PayByLinkProcessing
  • ReceiptSelection
  • SelectTestCard
  • SignatureVerification
  • WalletCodeEntry
  • WalletProcessing

Refunds

  • CashDrawerPrompt
  • CancelRefund
  • Exit
  • RefundCash
  • RefundCredit
  • RefundOptions
  • RefundPOA
  • RefundReceipt
  • RefundVoucher
  • RefundWallet

Device Management

  • DeviceDefinition
  • DeviceList
  • EditDevice
  • Exit

Cash Management

  • BankDeposit
  • CashAudit
  • CashCount
  • ConfirmTransfer
  • CountAcceptance
  • DrawerSelection
  • Exit
  • ModifyTransfer
  • OpenDrawer
  • PayIn
  • PayOut
  • RejectTransfer
  • RejectTransferFinish
  • ReserveInstructions
  • SafeDeposit
  • TransferAmount
  • TransferIn
  • TransferOut

Example usage

You can use the following convention to listen for and handle custom InStore events in your host application. The mistStatus event is shown as an example:
Example of how to listen for mistStatus in your appjavascript
window.addEventListener('mistStatus', (event) => {
  const { process, status, message } = event.detail;

  switch (status) {
    case 'success':
      console.log(`Process ${process} completed successfully.`);
      break;
    case 'cancelled':
      console.log(`Process ${process} was cancelled.`);
      break;
    case 'error':
      console.error(`Process ${process} failed: ${message}`);
      break;
    case 'activated':
      console.log(`Process ${process} was activated.`);
      break;
    default:
      console.log(`Unknown status: ${status}`);
  }
});