Skip to content
English
  • There are no suggestions because the search field is empty.

How Packages, Generic Groups and Custom Pricing Work in Fisikal

Understand how package driven groups behave, what changed in the logic, and how to correctly apply custom pricing using bundles.

Overview

This article explains how packages, generic groups, and custom pricing interact in Fisikal. It also covers a corrected system behaviour and the recommended approach for maintaining long-term pricing groups so members continue to receive the correct pricing on ad-hoc products purchased as part of their membership tier.


Generic groups and package behaviour

What is a generic group?

A generic group is automatically created when Create Generic Group = Yes is enabled on a package.

System behaviour

  • The user is added to the group when the package is assigned.
  • The user is removed from the group when the package expires or is archived.

Key rule

Group membership = active package only.


Important logic update

Previous behaviour (incorrect)

  • Users remained in groups after package expiry or archival.

Current behaviour (correct)

  • Active package → user remains in group.
  • Inactive package → user is removed.

Why this matters

  • Ensures accurate entitlement control.
  • Prevents incorrect pricing application.
  • Maintains clean segmentation.

Common challenge

Typical requirement

You may want users to stay in a group for:

  • Custom pricing
  • VIP segmentation
  • Long-term access rules

Limitation

This is not supported directly because generic groups are strictly tied to active packages.


Recommended solution: bundles

Strategy

Separate service delivery from pricing control using a bundle structure.

Step 1: Create the primary package (credit-bearing)

Used for:

  • PT sessions
  • Classes
  • Core services

Important: the generic group on this package should be deactivated (see the critical configuration section below).

Step 2: Create the secondary control package (membership pricing package)

Configuration:

  • Enable generic group on this package — this is essential.
  • Add a non-functional credit (see the recommended setup below).
  • Keep the package active long-term.

Purpose: maintains group membership and acts as the pricing anchor for the membership tier.

Recommended setup for the non-functional credit

To create a clean, non-bookable credit for use inside the membership pricing package, we recommend operators set up a dedicated structure rather than reusing existing service items:

  1. Create a new service category called Membership.
    • This category should have no schedule capabilities — it must not appear on any bookable schedule.
  2. Create a new activity type called Administration.
    • This keeps administrative items clearly separated from real client-facing activities.
  3. Create a new service called Membership under the new category and activity type.
    • Ensure the service is not bookable by clients.
    • This is the credit that will be added into the membership pricing package.

This Membership credit is then added to the secondary control package — the membership pricing package — which is assigned to the client through the bundle. Because the credit is non-bookable and the category has no scheduling, the credit cannot be consumed and the package stays active long-term, keeping the user in the generic group and the pricing intact.

Step 3: Create the bundle

Bundle both packages together:

  • Primary package → service delivery (credits the member can consume).
  • Secondary package → group membership and pricing control.

Step 4: Apply custom pricing

Apply pricing rules to the generic group linked to the secondary control package. See the critical configuration section below for the full step-by-step.


⚠️ Critical configuration: where to apply custom pricing

This is the most important part of the setup. Custom pricing must be applied to the generic group on the secondary control package (the membership pricing package included in the bundle), not to the primary credit-bearing package.

Without this, members will not receive the correct pricing on ad-hoc products they purchase as part of their membership tier — and you may also see conflicting prices if both packages have active generic groups.

Why this matters

  • The primary package's generic group disappears when credits are consumed or the package expires — pricing breaks.
  • The secondary control package is configured to stay active long-term, so its generic group persists — pricing holds.
  • Having two active generic groups (one on each package) creates duplication and ambiguity in how pricing rules are applied.

Required configuration steps (in order)

1. Enable the generic group on the secondary (membership pricing) package

  • Open the secondary control package inside the bundle.
  • Set Create Generic Group = Yes.
  • Confirm the generic group is created and named clearly (e.g. Membership Tier — Gold).

2. Re-link all custom pricing rules to the secondary package's generic group

  • Identify every ad-hoc product or service that should carry membership pricing (e.g. PT top-ups, retail items, class drop-ins, guest passes).
  • For each product, update its custom pricing rule so that it links to the generic group on the secondary control package.
  • Remove or replace any pricing rules that previously pointed to the generic group on the primary credit-bearing package.

3. Deactivate the generic group on the primary credit-bearing package

  • Open the primary package (the one containing consumable credits such as PT sessions or classes).
  • Set Create Generic Group = No, or otherwise deactivate the linked generic group.
  • This is the final step — only deactivate after pricing rules have been re-linked, so members are not left without correct pricing during the transition.

End result

  • One source of truth for membership pricing: the generic group on the secondary control package.
  • The primary package handles credits and service delivery only — no pricing logic attached.
  • Members receive consistent, correct pricing on all ad-hoc products for as long as their bundle is active.

Resulting behaviour

When a user purchases the bundle, they receive both a usable service package and a control package. As a result:

  • The control package remains active long-term.
  • The user remains in the membership-pricing generic group.
  • Custom pricing continues to apply to all linked ad-hoc products.
  • When credits in the primary package are consumed or expire, pricing is unaffected because it is anchored to the secondary package.

Key takeaways

  • Generic groups depend on active packages only.
  • Expired or archived packages remove users automatically.
  • This behaviour is intentional and correct.
  • Persistent group membership requires a secondary package, a bundle structure, and separation of logic.
  • Custom pricing must be linked to the secondary control package's generic group, not the primary credit-bearing package's group.
  • Deactivate the generic group on the primary credit-bearing package once pricing has been re-linked.
  • Use a dedicated Membership service category, Administration activity type, and non-bookable Membership service to create the unusable credit inside the secondary package.

FAQ

Why was a user removed from a group?

Because their linked package is no longer active.

Can users stay in a group without an active package?

No. You must use a bundle with a secondary package.

What is the purpose of the secondary package?

To maintain group membership and act as the pricing anchor for ad-hoc products purchased under the membership tier — independently of service usage.

Does the secondary package need usable credits?

No. It should contain a non-bookable, non-functional credit. We recommend creating a dedicated Membership service category (with no schedule capabilities), an Administration activity type, and a non-bookable Membership service for this purpose.

Which generic group should custom pricing be linked to?

The generic group on the secondary control package (the membership pricing package). Never the primary credit-bearing package.

Should the primary credit-bearing package keep its generic group?

No. Once pricing rules have been re-linked to the secondary package, deactivate the generic group on the primary package to avoid duplication and ambiguity.


Support

If you need help, contact your account manager or raise a support request.