IMPLEMENTATION CHECKLIST – Help Center | SLASCONE

This checklist provides practical guidance for planning, implementing, testing, and operating a SLASCONE licensing integration.

The checklist applies to desktop software, server applications, SaaS solutions, virtual machines, devices, and other licensed environments. Not every item is relevant to every integration, but the main architectural decisions should be made before implementation begins.

A. BEFORE IMPLEMENTATION

DEFINE THE LICENSED UNIT

Define what one license assignment represents, for example a device, installation, user, server, SaaS tenant, environment, or application instance.
Decide whether one customer can have multiple licensed units, such as separate development, test, and production environments.
Make sure that the licensed unit matches the commercial model and can be identified reliably by the application.

DEFINE THE PRODUCT AND EDITION MODEL

Define the product's features, limitations, variables, constrained variables, and software releases.
Define which commercial packages or license templates should be represented as editions.
Select the appropriate Provisioning Mode: Named or Floating.
Select the appropriate Client Type: Devices or Users.

Provisioning mode and client type are fundamental edition properties. They determine how the resulting licenses behave and should therefore be defined before implementation begins. More details here.

DEFINE THE CLIENT_ID STRATEGY

Depending on the application, the client_id may be based on a hardware identifier, operating system machine ID, cloud VM ID, SaaS tenant_id, environment ID, platform installation ID, or a persistently stored random identifier, as explained here.

Define how the application generates or retrieves the client_id.
Confirm that the identifier uniquely represents the actual licensed unit.
Confirm that the identifier remains stable across normal updates, restarts, deployments, and system changes.
Define what should happen after reinstallation, cloning, backup restoration, hardware replacement, or loss of the stored identifier.

DEFINE THE ACTIVATION STRATEGY

Decide whether the client should send an explicit activation request.
Alternatively, configure activation upon license creation if the client_id is already known when the license is created.
Confirm whether activation is initiated by an end-user application, a SaaS backend, an onboarding workflow, or another system.

Automatic activation or pre-activation is particularly useful for hardware and IoT scenarios, SaaS tenants, automated provisioning, and legacy migration scenarios. When activation upon license creation is enabled at the edition level, creating the license is sufficient and no separate activation request is required.

For details, see Activation upon creation options.

DEFINE THE CONNECTIVITY MODEL

Decide whether completely offline or air-gapped environments must be supported through file-based activation.
Decide whether temporary offline usage based on cached license data is allowed.
Define how long previously validated license data may be used without successfully contacting SLASCONE.
Define when online clients should send heartbeats, for example periodically, at application startup, during user login, or after another relevant application event.

For offline scenarios, see Offline Scenarios.

DEFINE THE ENFORCEMENT POLICY

Decide how the application should behave when a license is invalid, unavailable, or cannot be refreshed.

Define whether an invalid license causes immediate blocking, a warning, restricted functionality, or a temporary grace period.
Define what happens when a license is expired.
Define what happens when a license is explicitly deactivated.
Define what happens when the license start date lies in the future.
Define how the application behaves during temporary network or service failures.

A hard enforcement policy normally blocks access as soon as the license is no longer valid. A soft policy may provide warnings, restricted functionality, or a defined grace period. The selected behavior should be a deliberate product decision and not an accidental result of error handling.

DEFINE ANALYTICS AND CONSUMPTION REQUIREMENTS

Decide which technical information should be included in heartbeats, such as software version, operating system, or environment information.
Decide whether product usage or consumption values should be reported to SLASCONE.
Define the reporting frequency and aggregation level.
Avoid sending personal data unless it is required for the licensing or analytics scenario.

Analytics is not required for basic license enforcement. However, it should be considered before implementation because the required data, reporting events, and identifiers may affect the integration design.

B. IMPLEMENTATION

START WITH THE OFFICIAL EXAMPLES

Use the official SLASCONE GitHub examples as the starting point for the integration, since these already adress the majority of the issues of this article.
Use the official SLASCONE NuGet client for .NET integrations.
Keep the licensing integration isolated in a dedicated service or component rather than distributing licensing logic throughout the application.

AVOID HARD-CODED COMMERCIAL LOGIC

Do not base application behavior on edition names such as Basic, Professional, or Enterprise.
Do not hard-code license IDs, edition IDs, customer IDs, or customer numbers into the application.
Evaluate the product, features, limitations, variables, and other entitlements returned by SLASCONE based on their IDs.
Verify that a new edition based on existing licensing elements works without requiring a new application release.

Stable technical feature or limitation keys can form part of the integration contract. Commercial edition names should not. For example, the application may check whether a specific feature is enabled, but it should not assume that the feature is available only because the license belongs to an edition named Enterprise.

PROTECT CREDENTIALS AND SECRETS

Secrets should never be hardcoded in plain text directly in source code or configuration files that are distributed to customers without any protection, as explained here.

IMPLEMENT HEARTBEATS

In most online licensing scenarios, the first request sent by the application should be a license heartbeat.

Send heartbeats using the same stable client_id that was used for activation.
Send an activation request only if the heartbeat indicates that the client is unknown and explicit activation is required by the selected workflow.
Define a reasonable heartbeat trigger, such as every 24 hours, during application startup, or when a user logs in.
Prevent unnecessary repeated heartbeat calls for the same client, tenant, or instance.
Update the locally cached entitlement state after a successful heartbeat.

More information about heartbeat behavior can be found in Understanding SLASCONE.

IMPLEMENT A LICENSING STATUS VIEW

The application should provide a licensing view that clearly shows the current licensing state. Depending on the licensing scenario, this view may be read-only or may also allow authorized users to perform licensing-related actions.

The licensing view may be located in an administration area, settings page, about dialog, support view, or another suitable location. For headless services or backend applications, the same information and actions can be exposed through a protected administration interface or diagnostic endpoint.

The view should clearly distinguish between relevant licensing states, for example:

Licensed and valid
Unlicensed or unknown client
Not yet valid
Expired
Deactivated
Temporarily offline and using cached license data
Unable to contact the licensing service

ACTIVATE

In centrally managed or automatically provisioned environments, the licensing view may only display the current state and diagnostic information.

In self-service scenarios, the same view should provide the controls required to activate the application, for example by entering a license or token key, importing an activation file, or starting another supported activation workflow.

REFRESH

The licensing view should always provide a Refresh action. For online integrations, refreshing the view should explicitly send a license heartbeat to SLASCONE and update the displayed licensing state and entitlements based on the response. It should not only reload previously cached information.

In completely offline scenarios, the refresh action should re-read and validate the latest available offline license or activation file.

UNASSIGN

Where license reassignment or migration scenarios must be supported, the view may also provide an Unassign or Deactivate action.

This allows the current client assignment to be released before the license is activated on another device, installation, environment, or instance. The action should require appropriate authorization and a clear confirmation because it changes the active license assignment.

STATUS AND DIAGNOSTICS

Where appropriate, the licensing view should display the technical identifiers and information required for troubleshooting:

client_id
license_id
product_id
Current edition or entitlement configuration
License expiration date and relevant validation state
Time of the last successful activation or heartbeat
Whether the application is currently using live or cached license data

Ideally, users should be able to copy this information as a diagnostic summary and include it in a support request. Technical identifiers and licensing actions should only be available to appropriately authorized users. Credentials, API keys, complete token keys, signatures, and other secrets must not be displayed.

IMPLEMENT LICENSING LOGS

The licensing service or licensing component should produce meaningful, structured logs for all licensing-related operations.

Every SLASCONE API call should produce a log entry that makes it possible to understand which operation was performed, for which client, and with which result.

Each log entry should contain the relevant context whenever available:

Timestamp
SLASCONE API operation or endpoint
HTTP method and response status
Request duration
client_id
product_id
license_id, if known
Correlation or request identifier, if available
SLASCONE error ID and a meaningful error description

The licensing component should also log important local decisions and state transitions, for example:

A client changed from licensed to invalid, expired, or deactivated
Cached license data was used because SLASCONE could not be reached
An offline or grace period started or ended
An activation was triggered because a heartbeat returned an unknown client
A retry or fallback policy was applied

Use consistent structured fields so that logs can be searched and correlated across requests. The client_id and product_id should be included in every licensing-related log entry where they are available. The license_id should also be included after the relevant license has been identified.

Do not log credentials, API keys, complete token keys, private signing material, complete signed license files, or other sensitive values. Where a sensitive identifier is needed for correlation, use a masked or hashed representation.

IMPLEMENT LOCAL STORAGE AND OFFLINE BEHAVIOR

Store the identifiers required to associate the local application with the SLASCONE license and activated client.
Protect cached license and entitlement data against accidental modification.
Verify the signature of file-based or signed offline license data before accepting it.
Bind locally stored license data to the expected product, license, and client_id where applicable.
Enforce the defined maximum offline or grace period.

For general storage guidance, see What and how to save in your client.

IMPLEMENT ANALYTICS AND CONSUMPTION REPORTING

Include the agreed technical information in heartbeats.
Send consumption events when the commercial model depends on usage, quotas, credits, tokens, or another consumption metric.
Avoid sending the same event multiple times if a request is retried.
Verify that units, aggregation periods, and identifiers are consistent across all reporting calls.

C. FINAL VERIFICATION

RETRY AND FALLBACK POLICY

Implement and test a retry and fallback policy as described in Retry and fallback considerations.

REPLAY AND COPY PROTECTION

Implement and test replay protection as described in Digital Signatures, Data Integrity and Replay Protection.

TEST THE COMPLETE LICENSE LIFECYCLE

Test all relevant license states and operational scenarios in a production-like environment:

Valid and active license
License with a future start date
Expired license
Explicitly deactivated license
Changed features, limitations, or variables
New edition created without an application update
Duplicate or changed client_id
Temporary network failure and service timeout
Maximum offline or grace period reached
Application reinstallation, system cloning, backup restoration, and hardware changes
Offline or file-based activation, if supported
Activation, refresh, and unassign actions in the licensing view
Correct licensing state and diagnostic identifiers in the licensing view
Complete and traceable licensing logs without exposed secrets

GO-LIVE CHECK

Verify the complete integration in a production-like environment.
Separate development, test, and production environments and credentials.
Confirm that production credentials and locally stored license data are protected appropriately.
Confirm that monitoring detects activation, heartbeat, validation, consumption, and licensing-service failures.
Document who is responsible for licensing incidents and how they are investigated and resolved.

D. RECOMMENDED OPERATIONAL ENHANCEMENTS

The following capabilities are not required for the initial integration, but they can improve customer experience and operational visibility.

EXPIRATION ALERTS

Notify the vendor, reseller, customer, or license administrator before a license expires.
Define more than one warning point where appropriate, for example 30, 14, and 7 days before expiration.
Show an appropriate in-application warning before hard enforcement begins.

CONSUMPTION ALERTS

Notify relevant users when consumption reaches defined thresholds.
Distinguish between warning thresholds and the actual consumption limit.
Define what happens when the licensed consumption amount has been exhausted.

OPERATIONAL ANALYTICS

Monitor active clients, software versions, operating systems, and last heartbeat times.
Identify clients running outdated or deprecated software versions.
Monitor failed activations, invalid licenses, and inactive clients.
Use consumption and usage data to support customer communication, renewals, product decisions, and capacity planning.