THE ESSENTIALS

Security defines who can access CRM.COM and what they are permitted to do - from the people who run the business day-to-day, to the external applications that call CRM.COM's Web APIs.

Everything in this area answers one of three questions:

• Who are you? - Users, invitations, sign-in credentials, and the authentication rules that protect them: strong passwords, expiry periods, two-factor authentication, and single sign-on.

• What can you do? - User Roles and API Key Roles, which bundle permissions and assign them to people or to machines.

• What happened? - Webhooks, Events, and Logs, which allow the business to monitor, replay, and audit activity across the platform.

Who this manual is for

🔧 Configurator - sets up the security framework: creates User Roles and API Key Roles, defines password and session policies, enables 2FA and OpenID Connect, and generates API Keys. Works in Settings → Security.

🖥️ Operator - manages day-to-day access: invites users, assigns roles and teams, activates and deactivates accounts, clears lockouts, and monitors webhook deliveries.

🔗 Integrator - connects external systems: consumes CRM.COM Web APIs using API Keys, subscribes to Webhooks, and exports Events and Logs. For full integration guides and code examples, refer to the Integrators Hub and the Self-Service SDK documentation.

Key Concepts

Users and User Roles

A User is a person who works in CRM.COM - processing orders and service requests, monitoring performance, configuring the platform - through the back-end UI or via the Web APIs, subject to Business Network and security restrictions.

A User Role is a named bundle of permissions that determines what a user can see and do (e.g. manage Contacts, configure Reward Offers, maintain the product catalogue). Every user has exactly one role, assigned at invitation and changeable later.

The Owner Role

When an organisation is created, an Owner role with full access is generated automatically and assigned to the registering user. The Owner role is protected - it cannot be edited, copied, or deleted - and grants complete administrative control. Use it to bootstrap the organisation, then create tailored roles for everyone else.

Full Access vs. Restricted Access

A role either grants full access across all areas or restricted access to specific areas. Restricted roles are built area by area, within an area, access can be limited down to individual actions (e.g. allow viewing Contacts but not editing them).

Managing User Roles & Users

CLOUD OPERATOR SERVICE OWNER BUSINESS MERCHANT/SERVICE PROVIDER

User Roles

🔧 Primarily: Configurator

Create User Roles and assign permissions before inviting users, so each invitation can be given the correct role from the outset.

Create a role - Settings → Security → User Roles → Create User Role

1. Enter a unique name and, optionally, a description.

2. Permissions are grouped into Areas, each displayed as a card. Enable the toggle for an area to grant access, or use Select all to enable the entire area at once.

3. Restrict within an area by enabling only the specific action toggles required.

4. Save.

[Screenshot: Create User Role - permission area cards with per-action toggles]

Permission dependencies. Turning a permission on automatically enables any permissions it requires, turning one off automatically disables any that depend on it. A role cannot, for example, grant an edit action without its underlying view access.

Masquerade. The Allow to masquerade permission lets a user act within child organisations across the Business Network. A sub-toggle, Allow to create/manage data, controls whether the user can only view or also create and modify data whilst masquerading. See the Business Network manual for full coverage.

🔧 Configurator: The permissions displayed are filtered to the current organisation level - only toggles relevant to the organisation type are shown. Review every area before saving, an unset toggle means no access.

Manage roles. From the User Roles list, each role offers View, Edit, Copy (duplicate as a starting point), and Delete. A role marked as the Owner role displays a green "Used as owner role" badge and cannot be edited, copied, or deleted. A role eligible to cascade to child businesses shows "Can be used across child business network."

Users

🖥️ Primarily: Operator

Inviting a user creates their account with the permissions of the assigned role.

Invite a user - Settings → Security → Users → Invite User

1. Enter First Name, Last Name, and Email (the email becomes the sign-in identity and the destination for the invitation).

2. Select a User Role (mandatory).

3. (Business only) Assign one or more Teams.

4. Save to send the invitation.

[Screenshot: Invite User form]

The invitee receives an email, completes verification, and sets a password. Their credentials are the invited email address plus that password. Users may access their own organisation's data and, via masquerade, the data of child organisations.

User lifecycle. A user remains Inactive from invitation until they accept and sign in for the first time, at which point they become Active. If the same person is invited to multiple Businesses under one Service Owner and has already signed in to one, subsequent invitations set them Active automatically.

Manage a user (from the Users list ⋯ menu):

Edit user - fields. First Name, Last Name, and Email (mandatory), Phone (optional), User Role (mandatory), Teams (Business only), Preferred Communication Language (used for notifications sent to the user), Preferred Software Language (the language of the back-end UI - changing it for the current user updates the interface immediately).

Search and views. The Users list supports free-text search by name, email, and phone, and filters for Status (Active / Inactive), Locked, Team, and User Role. Saved views: All Users, Active Users, Inactive Users, Locked Users.

Outstanding Invitations

🖥️ Primarily: Operator

Users who have been invited but have not yet signed in appear under Outstanding Invites, surfaced from the Users page when pending invitations exist.

[Screenshot: Outstanding Invites list]

For each pending invitation:

• Resend - re-send the invitation email.

• Revoke - cancel the invitation.

Invitations can be filtered by Team and User Role. When no invitations are outstanding, the page returns to the Users list automatically.

Teams

🖥️ Primarily: Operator

Teams group Business users by area of responsibility. A user may belong to multiple teams, teams can be assigned to carry out Activities, Leads, Orders, and Service Requests.

Create or edit a team - Settings → Security → Teams → Create Team

• Name (mandatory, up to 64 characters) and Description (optional).

• Each team card shows its member count.

Membership is managed on the user, not the team - add teams during Invite User or later via Edit User. Delete a team from its ⋯ menu.

Security Policies

🔧 Primarily: Configurator

These policies control how users (and, where noted, contacts) authenticate. Each is found under Settings → Security and takes effect only when its toggle is enabled.

Strong Password Policy

BUSINESS

Enforces secure passwords, independently for users and for contacts.

[Screenshot: Strong Password Policy settings]

User strong password rules (when enabled):

• Configurable minimum length (defaults to 9 characters).

• Must include at least one upper-case letter, one lower-case letter, and one number.

• Supports alphanumeric and special characters.

• Must not be a sequence (e.g. abcdefg, 123456) or a previously used password.

Contact strong password rules (when enabled):

• Minimum 8 characters, alphanumeric and special characters supported.

• Must not be a sequence or the immediately preceding password.

If a user belongs to multiple organisations with different policies, the strictest policy applies.

Password Expiration Policy

SERVICE OWNER BUSINESS

Requires users to reset their password periodically. A user may reset on the expiry day at sign-in, or in advance via My Profile → Change Password.

[Screenshot: Password Expiration Policy settings]

• Expiration period - the number of days a password remains valid. Valid range: 14–730 days.

• Expiration notification - how many days in advance users are warned. Must be at least 1 and less than the expiration period.

Inheritance. If the Service Owner sets this policy, it applies across the Business Network. A Business may set its own policy, which overrides the Service Owner's - but the Business values must be equal to or less than the Service Owner's. (Example: if the Service Owner sets 60 days, a Business may set 60 or fewer.)

Two-Factor Authentication (2FA)

BUSINESS

2FA adds a second verification step after username and password. The second factor is a time-based code from an authenticator app (e.g. Google Authenticator, using the industry-standard TOTP algorithm) or a one-time password (OTP) delivered by email or phone.

[Screenshot: Two-Factor Authentication toggle and configuration]

Enable the toggle to require 2FA for the organisation's users. Eligible users then configure one or more 2FA methods from their profile. Any TOTP-compatible authenticator app is supported.

OpenID Connect (SSO)

BUSINESS

OpenID Connect allows users to sign in to CRM.COM using credentials from an external identity provider (single sign-on). Enable the toggle and supply:

[Screenshot: OpenID Connect configuration panel]

• Configuration Document URL - the provider's OIDC configuration endpoint.

• Application ID - the business's OIDC application identifier, supplied by the provider.

• Client Secret - the secret paired with the Application ID.

If OpenID Connect is not included in the licence, the card is visible but disabled.

Password Lockout (Core Behaviour)

Password lockout is always active and is not configurable.

• A user is locked out after five failed sign-in attempts within a 15-minute window (given a valid username). A locked-out user cannot authenticate - even with the correct password - until the lockout is lifted.

• The lockout clears automatically after 30 minutes, or immediately when an authorised Operator runs Cancel Lockout on the user (see Managing User Roles & Users above).

API Key Roles, API Keys & Webhooks

SERVICE OWNER TRANSACTION PROCESSOR BUSINESS

API Key Roles

🔧 Primarily: Configurator

An API Key Role is a bundle of permissions that controls which actions an API Key may perform - the machine equivalent of a User Role. API Key permissions are a subset of User Role permissions: only actions relevant to an external system are included.

Create a role - Settings → Security → API Key Roles → Create API Key Role

• Name (mandatory) and Description (optional).

• Enable permission areas and actions using the same Select all and dependency behaviour as User Roles.

• Roles support View, Edit, Copy, and Delete, each card shows the number of permissions granted.

When a new Business registers, a POS Integration API Key Role is created automatically for basic point-of-sale integrations.

API Keys

🔧 Primarily: Configurator · 🔗 Also: Integrator

API Keys are unique identifiers that allow a client application - mobile app, POS terminal, or external system - to consume CRM.COM's Web APIs.

[Screenshot: API Keys list showing Public and Secret key badges with status indicators]

Two types:

Multiple public and secret keys are supported. One public key may be designated the Default key for organisation identification, default keys are protected and carry no row actions.

Create a key - Settings → Security → API Keys → Create API Key

1. Name (mandatory).

2. Type - Public or Secret.

3. API Key Role - required for Secret keys, optional for Public.

4. IP Whitelist (optional) - restrict the key to specific IP addresses or subnets, each with a label. Calls from unlisted addresses are rejected.

5. Save.

Viewing the key value:

• Public keys display their value openly, with a copy button.

• Secret keys are shown only once, at creation (the Show Key dialogue), and are obfuscated thereafter. The value must be copied and stored securely at that point. A secret key authenticates API calls via an api_key header.

Rolling (regenerating) a Secret Key. Available for active Secret keys via ⋯ → Roll. Setting an optional expiry date allows the old key to remain valid during a transition window, omitting it revokes the old key immediately. Rolling produces a new key value, shown only once. Editing a key permits renaming, toggling Active / Inactive, and adjusting the IP whitelist, the key type cannot be changed.

Search and views. Filter by Type, Status, and API Key Role. Saved views: All, Public, Secret.

🔗 Integrator: Use a Public key for self-service and consumer flows, use a Secret key - with a least-privilege API Key Role and an IP whitelist - for server-to-server calls. Rotate secrets using Roll rather than deleting and recreating. See the Integrators Hub for authentication details and request signing.

Webhooks

🖥️ Primarily: Operator · 🔗 Also: Integrator

A Webhook is an automated HTTP call to an external server triggered by a specific event in CRM.COM, carrying real-time data about the entity involved. Webhooks are the delivery mechanism for Automations: a webhook is the action attached to an Automation event trigger. Webhooks are created and attached to events in Automations - refer to the Automations manual for the full event catalogue.

[Screenshot: Webhooks list showing pending, successful, and failed request counts per webhook]

Each webhook is defined with a name, an HTTP method (POST or PUT), a target URL, an authentication type (None, Username/Password, or API Key), and a retry policy (retry count and interval between attempts).

Monitoring and replay. From the Security area, webhook deliveries can be monitored and troubleshot:

• Each webhook card shows counts of pending, successful, and failed requests, with a link to that webhook's request log.

• The Webhook Requests page shows a status breakdown and every delivery attempt, filterable by state and created date.

• Expand a request to view its URL, authentication type, retry count, originating Automation, and a Request & Response viewer with the exact JSON payload sent and the response received.

• Replay re-sends failed requests - either all failed requests for a webhook, or individually selected ones.

Request states:

Events & Logs

🖥️ Primarily: Operator · 🔗 Also: Integrator

• Events capture business-level actions - for example, a contact registration or a new purchase.

• Logs capture technical activity - API requests and their responses.

Authorised users may review both for monitoring, troubleshooting, and auditing. Events and Logs can be exported to an external MongoDB database via CRM.COM Integrations for advanced analysis, long-term archival, or external processing.

Good To Know

Automations

The Webhooks section in Security handles delivery and monitoring. The event triggers that fire those webhooks are defined and managed in Automations. Navigate to Automations to create or edit the automation rules that call these webhooks, and to browse the full catalogue of available events.

Monitoring and Audit

The Security area provides two tiers of operational visibility:

• Integration health - the Webhooks list and Webhook Requests page give real-time delivery counts and allow replay of failed requests.

• Audit trail - Events and Logs provide a timestamped record of platform activity, reviewable in the back-end and exportable for long-term retention.

Integrations

🔗 Primarily: Integrator

Security exposes five integration surfaces. For step-by-step flows, schemas, error handling, and code examples, refer to the Integrators Hub and the Self-Service SDK documentation.

Reference Material

Business Network · Automations · Contacts

TABLE OF CONTENTS