Security and Access Control

Configure Firebase authentication for storefront login

Where to find it: This is configured automatically through your platform environment settings.

When you'd use this: When your storefront needs to authenticate customers using Firebase Identity Platform. This is required for customer login, registration, and password reset functionality on your storefront.

What you need first:

• Firebase project set up with Identity Platform enabled
• Firebase Web API key configured in your platform environment

How it works:

When customers interact with your storefront (logging in, creating accounts, or resetting passwords), the storefront communicates with Firebase using an API key. The platform automatically provides this key to your storefront through the settings API.

The Firebase API key is retrieved when your storefront requests authentication module settings from the platform. This happens automatically when the storefront loads, ensuring customers can authenticate without additional configuration on your part.

Troubleshooting:

• Customers can't log in or create accounts on the storefront — The Firebase API key may not be configured in your platform environment. Contact your platform administrator to verify that the Firebase Web API key is properly set in the identity-platform configuration.

• Authentication fails after a platform update — The Firebase API key configuration may need to be refreshed. Check with your platform administrator to ensure the key is still valid and properly configured in your environment settings.

Control Google reCAPTCHA fraud protection by customer type

When you'd use this: When you want to protect checkout from fraudulent orders using Google reCAPTCHA Enterprise, but need different protection levels for B2B customers, B2C customers, and guest shoppers. For example, you might enable fraud checks for B2C and guest customers while disabling it for trusted B2B accounts that may be blocked by automated verification.

What you need first:

• Google reCAPTCHA Enterprise configured in your platform environment
• Understanding of your customer base and which groups require fraud protection

How it works:

You can enable or disable Google reCAPTCHA fraud checking separately for three customer types: B2B customers (logged-in business accounts), B2C customers (logged-in individual shoppers), and guest customers (shopping without an account). This gives you flexibility to balance security and user experience for different audiences.

When enabled for a customer type, Google reCAPTCHA Enterprise analyzes checkout behavior to detect and prevent fraudulent transactions. When disabled for a customer type, those customers can complete checkout without reCAPTCHA verification.

Troubleshooting:

• Legitimate B2B customers are blocked at checkout — The fraud check may be enabled for B2B customers when it's not needed for your trusted business accounts. Consider disabling the fraud check for B2B customers while keeping it enabled for B2C and guest customers.

• Fraud check settings aren't taking effect — Contact your platform administrator to verify the store mode settings are properly configured for your store's default language.

• "AGENT_ISSUE - There is a configuration issue with the remote agent" error appears in Store Manager — This can occur when authentication tokens are issued by a different regional server than the one validating them, or during platform deployments when services are restarting. The platform handles these cross-region authentication scenarios automatically. If the error persists, contact your platform administrator to verify the authentication service configuration.

Manage store users and site administrators separately

Where to find it:

• Customers → Manage Store Users (/admin/customers/manage-store-users) — for B2B and B2C customers who shop on your storefront
• Settings → Site Admins (/admin/settings/site-admins) — for administrators who manage your store

When you'd use this: When you need to manage your customer base separately from your administrative team. Store users are the shoppers who purchase from your storefront (both B2B business accounts and B2C individual customers). Site administrators are the team members who manage your store through the admin interface.

How it works:

The platform maintains two distinct user populations:

Store Users include registered customers, business accounts, guest shoppers, and unapproved B2B accounts. These are the people who browse and purchase from your storefront. The Customers → Manage Store Users screen shows only these users — no administrators appear in this list.

Site Admins include Master Admins and Site Managers who have access to the admin interface. The Settings → Site Admins screen shows only administrative users. If you're logged in as a Master Admin, you'll see both Master Admins and Site Managers in the list. If you're logged in as a Site Manager, you'll see only other Site Managers — Master Admins are hidden from your view.

This separation makes it easier to find and manage the right type of user without sorting through mixed lists.

Using it day-to-day:

1. To manage customers who shop on your storefront, go to Customers → Manage Store Users. Use this screen to view customer activity, update customer details, or manage B2B account approvals.

2. To manage your administrative team, go to Settings → Site Admins. Use this screen to review who has access to your admin interface, check their roles, and manage administrator accounts.

3. The user group type information helps you identify what kind of access each user has. Store users have customer group types (like registered users, business accounts, or guest shoppers), while site admins have administrative group types.

Troubleshooting:

• I can't find a user I'm looking for — Check that you're on the correct screen. Customers appear only in Customers → Manage Store Users, while administrators appear only in Settings → Site Admins. A user can't appear in both lists.

• Some administrators are missing from the Site Admins list — If you're logged in as a Site Manager, Master Admins are intentionally hidden from your view. Only Master Admins can see other Master Admins in the Site Admins list.

• Sales representatives or custom user groups aren't appearing — Sales representatives and custom groups are managed separately and don't appear in either the Store Users or Site Admins screens. Contact your platform administrator if you need to manage these user types.

Configure store user groups and permissions

Where to find it: Users → Groups (/v5-admin/{lang}/users/groups)

When you'd use this: When you need to control what different types of customers can see and do on your storefront. For example, you might want B2B customers to see pricing and place orders, while guest shoppers can only browse the catalog without prices. Or you might need sales representatives to be able to place orders on behalf of customers.

What you need first:

• Understanding of your customer segments and what permissions each group needs
• For B2B groups: knowledge of which customer accounts should be assigned to each group

How it works:

Store user groups define what features and content are available to different types of customers. The platform includes built-in system groups for common customer types:

• B2B groups — REMOTE_CUSTOMER (approved business accounts), STORE_OUTLET (branch locations), GUEST (B2B guest checkout), UNAPPROVED_B2B (pending approval)
• B2C groups — PUBLIC_REGISTERED_USER (logged-in individual shoppers), PUBLIC_UNREGISTERED_USER (guest shoppers), PAYPAL_UNREGISTERED_USER (PayPal guest checkout)

You can also create custom groups with specific permission sets tailored to your business needs.

Each group controls permissions across eight areas:

1. General — Basic group settings including name, description, and status
2. Ordering & checkout — Whether members can place orders, add to cart, choose shipping addresses, backorder out-of-stock items, and whether new orders require approval
3. Payment — Available payment methods for the group
4. Catalog & pricing — Whether prices are visible, if members must log in to see prices, stock display settings, and warehouse availability
5. Sales rep — Whether sales representatives can assign themselves to customers or place orders on behalf of accounts
6. Category access — Which catalog categories members can browse
7. Admin privileges — Access to admin functions like catalog management, content, customers, marketing, orders, reporting, and settings
8. Password policy — Password requirements, expiration rules, and reuse restrictions for the group

The groups list shows all system and custom groups with their member counts. You can search by group name or type, and filter to show only system groups or custom groups. B2B system groups and custom groups can be edited; B2C public groups are read-only.

Using it day-to-day:

1. Go to Users → Groups to see all available user groups. The list shows each group's type (System or Custom), unique ID, and how many members belong to each group.

2. Use the search box to find a specific group by typing part of its name.

3. To edit a group's permissions, hover over the row and click Edit. (B2C public groups like PUBLIC_REGISTERED_USER and PUBLIC_UNREGISTERED_USER cannot be edited.)

4. In the group editor, review and adjust settings across the eight permission areas. Each toggle includes a plain-language description of what it controls.

5. To set category access, click Choose categories in the Category access section. A side panel opens where you can select which catalog categories this group can browse.

6. To configure the password policy, click Manage policy in the Password policy section. A side panel opens where you can set character requirements, expiration rules, and password reuse restrictions. The summary displays password requirements as specification chips and plain-English expiry/reuse rules.

7. When you make changes, a save bar appears at the bottom of the screen. Click Save to apply your changes or Cancel to discard them.

8. To manage a group's password policy from the list view, hover over the row and click Policy.

9. To delete a custom group, hover over the row and click Delete. You'll be asked to confirm before the group is removed.

Troubleshooting:

• I can't edit a system group — B2C public groups (PUBLIC_REGISTERED_USER, PUBLIC_UNREGISTERED_USER, PAYPAL_UNREGISTERED_USER) are read-only and cannot be edited. B2B system groups (REMOTE_CUSTOMER, STORE_OUTLET, GUEST, UNAPPROVED_B2B) and all custom groups can be edited.

• Changes aren't saving — Make sure you click Save in the save bar at the bottom of the screen after making changes. If you navigate away without saving, your changes will be lost.

• A setting I toggled doesn't affect the storefront — Some settings only work when connected features are enabled in your storefront. If a permission toggle doesn't produce the expected behavior, contact your platform administrator to verify that the related storefront feature is properly configured.

• I can't find the category selector or password policy editor — Click Choose categories or Manage policy to open the side panel. These editors open in a side sheet rather than requiring a full-page navigation.

Review and export audit logs

Where to find it: Admin → Audit → Logs (/admin/maudit/logs)

When you'd use this: When you need to track what changes have been made to your store data, who made them, and when. This is useful for compliance auditing, investigating data issues, reviewing team member activity, or understanding what changed before a problem occurred.

How it works:

The audit log page shows every create, update, and delete action performed on your store's data. At the top, summary cards display the total number of changes and break down the counts by action type (creates, updates, deletes).

Each log entry shows:

• Action type — Color-coded badges indicate whether a record was created (green), updated (blue), or deleted (red)
• User — The team member who made the change, displayed with their avatar and initials
• Role — The user's role at the time of the change
• Table — Which data table was affected (e.g., products, orders, customers)
• Value changes — For updates, you'll see the old value in red and the new value in green, making it easy to spot what changed
• Timestamp — When the change occurred

Using it day-to-day:

1. Use the filter bar to narrow down the logs:

   • Table dropdown — Filter by which data table was changed (or select "All Tables" to see everything)
   • Action dropdown — Show only creates, updates, or deletes (or select "All Actions")
   • User search — Enter a team member's name to see only their changes
   • Date range — Use the From and To date pickers to view changes within a specific period
   • Global search — Search across all log fields

2. Review the summary cards to get a quick overview of activity — they show the total number of changes and the breakdown by action type across all filtered results.

3. Browse through the log entries in the table. For updates, the Value Change column shows old values in red and new values in green, making it easy to see exactly what changed.

4. Click Export CSV to download the filtered logs for external analysis or record-keeping.

5. Click Refresh to reload the log data and see the most recent changes.

Troubleshooting:

• The Total Changes count doesn't match what I see in the table — The Total Changes card shows the count across all pages of filtered results, not just the current page. Use the pagination controls at the bottom to view additional pages.

• "All Tables" or "All Actions" dropdown appears empty after selecting it — This is expected behavior. When you select the "All Tables" or "All Actions" option to clear the filter, the dropdown will display that label even though the underlying filter value is empty.

• I can't find changes I know were made — Check your filter settings. Clear the Table, Action, User, and date range filters, then try searching again. Some changes may have been made by a different user or on a different date than expected.

Track changes to custom integration mappings

When you'd use this: When you need to investigate when custom mappings for your integration were added, changed, or removed, and who made those changes. This is especially useful when mappings unexpectedly change or need to be restored to a previous state, or when you need to verify that mapping updates were applied correctly.

How it works:

Every time a custom mapping override is created, updated, or deleted, the platform records who made the change, when it happened, what changed, and both the old and new values. This audit trail helps you understand the complete history of your integration mappings and resolve issues where mappings may have been inadvertently modified or reverted.

The change history shows:

• Action type — Whether a mapping was created, updated, or deleted
• Mapping — The specific mapping that was affected
• Changed column — Which field in the mapping was modified
• Old and new values — What changed (for updates)
• Changed by — The team member who made the change, or empty if the change was made by an automated process
• Timestamp — When the change occurred

You can filter the audit trail by specific mappings, search across all fields (including user names, mapping labels, column names, and values), and export the results for investigation or record-keeping.

Using it day-to-day:

1. To view the mapping audit trail, your platform administrator can query the mapping audit endpoint for your store and integration source.

2. Use the search parameter to find specific changes — you can search by team member name, mapping label, field name, or the actual values that were changed.

3. Filter by a specific mapping ID to see the complete change history for just that mapping.

4. Review the results to understand what changed, when, and who made the change. Changes made by automated processes will show an empty "changed by" field.

Troubleshooting:

• A mapping changed but I don't know when or who changed it — Check the mapping audit trail. If the "changed by" field is empty, the change was made by an automated process or a direct database update rather than by a user through the admin interface.

• Mappings reverted to a previous state unexpectedly — Review the audit trail to identify when the reversion occurred and whether it was made by a user or an automated process. This information can help your support team investigate what caused the change.

• I need to restore a mapping to its previous value — Use the audit trail to find the old value before the change, then update the mapping back to that value. The audit trail will record this restoration as a new change.