Understand the platform.
Down to the details.

Define each product, its identity, type and release, and bring your software portfolio together.

• The product is the unit around which plans, licenses and capabilities are organized; give each product its own identifier.
• Define Arabic and English names, type, state, release and distribution links where needed.
• Example: a code editor and publishing tool in one portfolio, each with an independent commercial policy.

Manage release information, distribution links, update messages and product-specific policies.

• Keep the announced release separate from customer configuration and license records.
• Update messages explain changes; product policy determines whether updating is optional or required.
• Review compatibility across old and new releases rather than assuming a new plan adds support to an older build.

Connect feature keys to release and platform support, with manifest synchronization.

• The manifest describes application capabilities, release and platform; it is not a purchase or license by itself.
• Synchronization helps organize registered capability keys and associate them with the product context.
• The application team declares support it has implemented, then separately reviews the rights granted by plans.

Distinguish a capability granted by a plan from one the application release actually supports.

• Three questions meet: does the customer own the product, does the plan grant the capability, and does this release support it?
• Explicit denials and complete support declarations matter; unknown support is not automatic permission.
• Example: do not expose a new export tool in a release that has not implemented it, even when the customer plan includes it.

Bring product records, plans, features, policies and administrative links into a connected context.

• The product workspace connects plans, capabilities and policies to reduce navigation and loss of context.
• Review the product, then move into its associated plan and entitlements.
• Useful for businesses with multiple product teams that need a clear administrative reference for each application.

Independent policies for software, systems and services, without implicitly transferring rights between products.

• Do not assume Pro or Ultimate means identical rights across two products.
• Desktop software, web systems and services can be organized within the model, with each client contract and integration reviewed.
• Account identity can be shared by design while product ownership and policies remain explicit.

Issue licenses and follow their state, validity, suspension and associations.

• A serial associates access with a license; validity also depends on state, product, duration, devices and policy.
• Follow license state, activation, validation and expiry in one registry.
• Administrative changes such as suspension or revocation should make their reason and effect clear.

Separate account identity, product ownership, license and plan so their relationships stay clear.

• The account is the sign-in identity; the customer profile is the commercial context; ownership associates the customer with a product.
• One account may own multiple products or licenses; a customer is not equivalent to a single serial.
• Administratively archiving a customer profile is different from revoking active ownership or a license.

Bring selected products under one shared serial while keeping each product’s plan and rights independent.

• Explicitly select the products included in a shared serial and choose each product’s plan.
• Product rights remain independent; buying another product does not silently attach it to every previous serial.
• Example: an editor on Pro and a publishing tool on Plus within one account and shared serial, without exchanging privileges.

Follow activated devices, hardware identity and activation limits under the license policy.

• Device count and activation limits are a policy distinct from each device’s identity.
• Administration reviews bound devices and recent contact; binding policy controls device release or reassociation.
• Device information or an IP address should not be treated as definitive proof of a person’s identity.

Configure connectivity requirements, grace periods and offline use according to client support and product policy.

• Product and license policies define connectivity requirements, and the integrated client must enforce them at runtime.
• Grace periods and offline entitlement leases can be configured within the defined limits.
• Test disconnection, lease expiry and reconnection; lack of connectivity does not imply permanent unlimited access.

Manage ownership and serial states while retaining their product context and history.

• Recovery follows record identity, history and administrative policy rather than creating unrelated replacement ownership.
• Restoring a record can require explicit reactivation and a limit review; recovery is not a policy bypass.
• Organize serial rotation and recovery within the product context while retaining follow-up history.

Define price, duration, currency and capabilities per product rather than relying on a plan name.

• Define name, description, duration, price and currency for each product plan.
• Grants come from plan policy; avoid hardcoding entitlement checks against a plan’s display name.
• Prices inside showcase screenshots are illustrative, not a price list for purchasing Sentinel itself.

Manage independent capability keys and groups to build product plans.

• Feature keys give capabilities stable identifiers while display labels can evolve.
• Groups organize related capabilities and simplify plan composition.
• Example: an export group includes PDF, batch operations and templates, each configured under policy.

Explicit grants, denials and limits with server-side policy decisions.

• Distinguish explicit grant, explicit denial and undefined state; absence is not equivalent to permission.
• Apply entitlements in the actual operation, not merely by hiding or restyling a button.
• The UI should explain unavailability and show an appropriate upgrade path where the product experience supports it.

Configure resource and consumption limits tied to the correct plan and ownership.

• A capability can be a permission, numeric limit or reserved resource; choose the model appropriate to it.
• Scope the counter to the correct product and ownership, reviewing period, unit and over-limit behavior.
• Example: a file-export allowance is different from a device limit or concurrent-operation limit.

Define trial, free and paid access policies appropriate to each product.

• Product policy defines trial duration, plan, repeat conditions and the behavior when access expires.
• Valid paid ownership should be resolved in context rather than unnecessarily creating a competing trial.
• Fallback to Free depends on an available, valid free plan; do not assume every product has one.

Record consumption and resource reservations and settlement under the service and entitlement contracts.

• Recording consumption is different from temporarily reserving a resource before an operation completes.
• Correct integration handles reservation followed by settlement or release according to the operation result.
• Usage records support follow-up; configuring a quota alone does not prove the client meters the correct operation.

Bring customer records, ownerships, products and assigned plans into one administrative context.

• Bring customer records, products, ownerships and plans together without conflating them with sign-in credentials.
• Views, search and archiving support commercial and administrative follow-up.
• Administrative archiving does not automatically revoke active access rights.

One account identity with multiple ownerships and separate customer and administrative sessions.

• Unified identity lets a customer see products within one account while keeping each ownership explicit.
• Customer and administrator sessions are separate to reduce overlap between administration and use.
• Session duration and remember-me behavior can be defined according to product policy and integration support.

A customer space for owned products, ownerships, requests and permitted account information.

• The portal exposes the account’s permitted data and owned products, not other customers’ records.
• Requests, keys and ownership actions are associated with the correct customer and product.
• Registration, email verification, sign-in and recovery journeys are reviewed during integration.

Organize requests, review and delivery, connecting activation to the correct ownership.

• A purchase or renewal request is a commercial request, not payment proof or an automatic license grant.
• Review and delivery follow the agreed operational process and link to the appropriate ownership and plan.
• External payment integration needs explicit scope, accounts and authorization; a request screen alone does not establish it.

Manage service subscriptions and associate credentials with the correct rights and context.

• A service subscription describes entitlement, duration and context; a credential enables access within its scope.
• Manage keys, rotation and revocation without exposing sensitive material in marketing pages or public logs.
• Review whether the service uses consumption, reservation or access-only rights when designing integration.

Organize resource and integration references within the customer workspace according to adapter scope.

• An administrative resource reference is not by itself proof of execution at an external provider.
• Adapter capabilities and the integration environment define what can actually be verified or executed.
• Businesses review service and provider scope during setup without assuming automatic support for every provider.

An overview of products, licenses, customers, usage, activity and upcoming expiry.

• The dashboard summarizes products, customers, licenses, states, usage and activity.
• Contextual navigation takes staff to records or a product workspace instead of stopping at aggregate counts.
• Commercial showcase figures are synthetic, not the developer company’s customer counts or a capacity guarantee.

Organize administrative permissions, sessions and security actions by role.

• Administrative roles, global permissions and section scopes organize who can view, edit, create and manage.
• Session tools include activity review and revocation governed by permissions and confirmations.
• Administrator two-factor authentication and recovery settings are available; rollout and handover policies are reviewed with the operator.

Review significant events with their actor and timestamp in an administrative record.

• Associate actions with actor, time and context to support administrative review and investigation.
• Do not use the audit trail to store passwords, signing keys or exposed credentials.
• An audit trail provides operational evidence; it is not by itself a compliance certification or an accredited external audit.

Backup schedules, protection policies and recovery previews with environment-specific prerequisites.

• Backup policy covers scheduling, retention, encryption and integrity verification.
• Recovery is preceded by review, comparison and an isolated rehearsal according to operator and environment requirements.
• System security keys and host migration require separate management; a backup alone does not replace a tested recovery plan.

Arabic and English guidance with contextual tool explanations and return-to-work navigation.

• Guidance connects an explanation to the tool and its purpose, with practical examples and steps.
• When contextual help is enabled, users can open a short explanation or navigate to detailed guidance.
• Arabic and English serve administration and integration teams while retaining technical terms where useful.

Inspect connectivity, identity and access decisions to understand application integration.

• Resolve the account, product, release and ownership before interpreting an allow or deny decision.
• Diagnostics distinguish connection failure, missing valid ownership, plan denial and unsupported release capability.
• Do not resolve integration errors by arbitrarily granting broader rights; review the cause in context.