Dictionaries - Overview

Introduction

The Dictionaries module acts as the central configuration hub for managing the various drop-down lists, categories, and system enumerations used throughout the application. By centralizing these definitions—ranging from 'Lead Status' and 'Campaign' sources to 'Training Type' and 'Document Type'—administrators ensure data consistency, accurate reporting, and a streamlined user experience across all system areas. This tool allows for the rapid customization of system terminology to match your specific business processes and naming conventions.

Feature Description

To access Dictionaries, go to the PGM->Settings->Dictionaries

Settings

This section details the specific configuration options available when managing dictionary entries. These settings control how options appear to users and how the system processes them.

• Dictionary Name (Category)

  • Description: Represents the high-level grouping or type of list being modified. This is the container for individual items.

  • Example: Selecting "FacilityBookingDuration" to configure the time slots available for booking, or "Due Date Schema" to manage payment timelines.

• Item Name (Value)

  • Description: The actual text label that will appear in the drop-down list for end-users. This should be clear, concise, and distinct from other options.

  • Example: Entering "Passport" or "Driver's License" as an Item Name within the "Document Type" dictionary.

• System Key

  • Description: An internal identifier used by the software logic to recognize specific standard values, regardless of their display name. Often read-only for core system functions.

  • Example: The 'Lead Status' dictionary may have a System Key of "new" or "converted" which triggers specific automated workflows, even if you rename the display label to "Fresh Lead."

• Translations

  • Description: Allows the definition of Item Names in multiple languages, ensuring the interface adapts to the user's selected language profile.

  • Example: Providing the Spanish value "Entrenamiento Personal" for the "Training Type" entry "Personal Training."

Dictionary Name (Category)

This module allows administrators to configure various dictionary types that control available options in dropdowns and selectors throughout the system.

Banking report category

• Description: Classifies entries within banking reports, likely for separating different types of transactions or financial events.

• Example:

  • Key:

  • Value:

Banking report group

• Description: A higher-level grouping mechanism for aggregating multiple BankingReportCategory items together.

• Example:

  • Key:

  • Value:

Cancellation delivery method

• Description: Defines the methods by which a membership cancellation request was delivered.

• Example: Email, In-Person, Certified Mail

  • Key: Email

  • Value: Email

Client flags

• Description: Binary flags or markers for specific alerts on a client account. Key must be a hex colour code eg. #FF0000

• Example:

  • Key: #FF0000

  • Value: #FF0000

Client tags

• Description: Custom tags that can be attached to client profiles for quick identification (e.g., "High Risk", "Frequent Traveler").

• Example:

  • Key: High Risk

  • Value: High Risk

Club equipment type

• Description: Types of equipment listed for a club (e.g., "Treadmills", "Free Weights", "Cardio Machines"). This is set in PGM->Clubs->List of Clubs under Club Info.

• Example:

  • Key: Treadmills

  • Value: Treadmills

Club facility type

• Description: Amenities or facilities available at a club location (e.g., "Sauna", "Swimming Pool", "Parking"). This is set in PGM->Clubs->List of Clubs under Club Info.

• Example:

  • Key: Sauna

  • Value: Sauna

ContactSubType

• Description: A sub-category for a contact.

• Example: Corporate Contact, VIP Client, Former Member

  • Key: Former Member

  • Value: Former Member

CrmRating

• Description: Indicates the "temperature" or potential of a lead.

• Example: cold, warm, hot

  • Key: warm

  • Value: warm

Department

• Description: Definition of departments used for fiscalization. Not to be confused with employee departments.

• Example:

  • Key:

  • Value:

Allowed direct debit country symbols

• Description: This type stores a list of country symbols (ISO 2-letter codes) supported for Direct Debit operations. It is used to determine validation masks for IBAN, Bank Codes, and Postal Codes for different regions.

• Example: PL, DE

  • Key: PL

  • Value: PL

Document shipping type

• Description: Methods available for delivering documents to clients (e.g., "EmailShipping", “PostalShipping“).

• Example:

  • Key: EmailShipping

  • Value: EmailShipping

Due date scheme

• Description: Configurations for how payment due dates are calculated. This is set using a formatted code. Set in PGM->Sale->Payment Plans. With Use advance due date schema policy for contract fees checked and a value selected in the drop down box Due Date Schema.

• Example:

  • Key: J0;J0;D0;12_J0

  • Value: administration fee, prorata and 12th membership fee due on contract signature date. Remaining membership fees due dates unchanged/default.

Employment Type

• Description: The form of employment contract for staff members.

  • Usage: The Employee has a property EmploymentType, allowing different contract types like "Full-time", "Part-time", or "B2B" to be assigned to employees.

• Example:

  • Key: Full-time

  • Value: Full-time

FacilityBookingDuration

• Description: Sets standard time slots available for booking resources or facilities.

• Example: Add a "90 Minutes" option to allow members or staff to reserve a tennis court for an extended hour-and-a-half session.

  • Key: 90

  • Value: 90

InquiredVia

• Description: Describes how the lead first contacted the facility.

• Example: walk-in,webForm,phone,socialMedia

  • Key: socialMedia

  • Value: Social Media

LeadStatus

• Description: Tracks the current state of a sales lead.

• Example: new, converted, dead, contacted, appointmentScheduled, thinking

  • Key: contacted

  • Value: contacted

Marketing Action

• Description: Types of marketing initiatives or events.

• Example: "Email Campaign", "Open Day", "Promo Booth"

  • Key: ABC123

  • Value: ABC123

Marketing Detail Factor

• Description: Granular details or factors associated with the marketing source

• Example: specific ad campaign ID or referral program name.

  • Key: ABC123

  • Value: ABC123

Marketing Detail Source

• Description: The source from which a user or lead was acquired.

• Example: The standard system keys for this type: "walk-in", "referral", "facebook", "instagram", "webSearch", "adwords".

  • Key: referral

  • Value: referral

MeetingSubtype

• Description: Further classifies generic interactions (Meetings).

• Example: trialTraining (Introduction session), consultation, salesMeeting

  • Key: consultation

  • Value: consultation

MeetingType

• Description: Specifies the nature of a meeting.

• Example: Sale, Opportunity, Check-in

  • Key: Sale

  • Value: Sale

Document type

• Description: Classifies documents uploaded or attached to a member's profile

• Example: ID Scan, Medical Certificate, Student ID

  • Key: Medical Certificate

  • Value: Medical Certificate

OpportunityRejectionReason

• Description: Reasons why a lead or opportunity was lost.

• Example: other, not interested, cost

  • Key: cost

  • Value: cost

OpportunityType

• Description: Classifies the type of sales opportunity being pursued.

• Example:pProduct, service, paymentplan

  • Key: service

  • Value: service

Payment plan categories

• Description:Used to group Payment Plans into logical categories for reporting or UI organization (e.g., Gold, Silver, Bronze).

• Example:

  • Key: Bronze

  • Value: Bronze

Payment plan relation type

• Description: Sets custom relation types in Payment Plans when using the relation feature.

• Example: Add a "Friend" option so that a payment plan can be connected with the type “Friend“.

  • Key: Friend

  • Value: Friend Relation Type

PersonalTrainingDuration

• Description: Sets a custom personal training session duration

• Example: Add a "50 Minutes" option to allow staff to book personal training sessions for 50 minutes.

  • Key: 50

  • Value: 50

PhoneCallType

• Description: Specifies the purpose of a phone call.

• Example: Confirmation Call, Sales Call

  • Key: Sales Call

  • Value: Sales Call

PhoneSubtype

• Description: Further classifies generic interactions (Phone Calls).

• Example: confirmationCall (Confirming an appointment), inquiryCall, salesCall

  • Key: inquiryCall

  • Value: inquiryCall

Priority

• Description: Used for tasks or lead prioritization.

• Example: low, medium, high

  • Key: medium

  • Value: medium

Product Inventory Type

• Description: Categorizes products based on their inventory tracking method or physical nature.

• Example: Stocked Item, Service, Consumable.

  • Key: Supplements

  • Value: Supplements

ReferralCampaignSettings

• Description: This dictionary type is used to store configuration settings for referral campaigns, typically serialized as JSON.

• Example: NA

  • Key: NA

  • Value: NA

RejectionReason

• Description: The reason a lead or opportunity was unsuccessful.

• Example: Dead, Other

  • Key: Other

  • Value: Other

Numbering series

• Description: A numbering series for a document. When a new invoice is generated, it can be assigned to a Series, which would determine its document number prefix and sequence.

• Example: INV/2024/, VAT/2024/

  • Key: VAT/2024/

  • Value: VAT/2024/

Service call result

• Description: Defines the outcome of the service call.

• Example: Successful, Unanswered, Rejection

  • Key: Unanswered

  • Value: Unanswered

Service call type

• Description: Defines the purpose of a service call.

• Example: Upsell, Promotion, check-in

  • Key: Upsell

  • Value: Upsell

Notification type

• Description: Defines the specific categories of notifications that the system can generate or send to users. This helps in filtering and prioritizing automated alerts.

• Example: Configuring a type named "Maintenance Alert" allows you to categorize notifications related to facility repairs separately from "Payment Reminders."

  • Key: Maintenance Alert

  • Value: Maintenance Alert

TaxOffice

• Description: Stores a list of relevant tax office names and details, primarily used when configuring billing information for Corporate Clients.

• Example: Adding "Second Tax Office of Warsaw" ensures that when setting up a new corporate partner in the system, the correct tax authority can be selected from a standardized list.

  • Key: Second Tax Office of Warsaw

  • Value: Second Tax Office of Warsaw

Class duration

• Description: Sets the valid duration intervals (in minutes) available when creating or scheduling classes and bookings in the timetable.

• Example: Adding the value "45" allows instructors to schedule 45-minute sessions, whereas the default might only show 30 or 60-minute blocks.

  • Key: 45

  • Value: 45

Training type

• Description: Categorizes the different styles of workouts or classes offered, used for filtering class schedules and reporting on facility usage.

• Example: You might define types such as "HIIT," "Yoga," and "Personal Training" to distinctively track attendance and popularity for each category.

  • Key: Yoga

  • Value: Yoga

User Designation

• Description: Specifies professional titles or roles that can be assigned to users or staff members, often used for display on profiles or in reports.

• Example: Setting up values like "Senior Trainer" or "Nutritional Consultant" allows you to accurately reflect staff hierarchies and specializations on their profiles.

  • Key: Nutritional Consultant

  • Value: Nutritional Consultant

User document system type

• Description: Classifies the various types of documents that the system generates automatically for users, facilitating organized document management and retrieval.

• Example: Defining a type called "Liability Waiver" ensures that all auto-generated waiver PDFs are stored under this specific category, separating them from "Invoices."

  • Key: Liability Waiver

  • Value: Liability Waiver

User PosTx Delete Reason

• Description: Provides a mandatory list of justifications that a staff member must select when deleting a transaction at the Point of Sale (POS). This is critical for audit trails.

• Example: Creating a reason "Cashier Entry Error" allows management to track how often transactions are voided due to mistakes versus actual refunds.

  • Key: Cashier Entry Error

  • Value: Cashier Entry Error

User Rejected Reason

• Description: Lists the standard reasons why a user's application, entry, or specific request might be denied by the system or a staff member.

• Example: A value of "Medical Contraindication" could be selected if a member is denied entry or participation in a high-intensity event due to health safety protocols.

  • Key: Medical Contraindication

  • Value: Medical Contraindication

User Status

• Description: Defines the various states a user account can hold, which may trigger specific system behaviors or access rights (e.g., access control barriers).

• Example: Beyond standard "Active" or "Inactive," you might add "Suspended - Payment Due" to visually flag members who are temporarily blocked until they settle their account.

  • Key: Inactive

  • Value: Inactive

User Transaction Delete Reason

• Description: Similar to POS deletions, this dictionary standardizes the reasons for removing financial transactions from a user's ledger in the back-office.

• Example: Using a reason like "Duplicate Charge" helps accountants quickly identify and reconcile corrections during end-of-month reporting.

  • Key: Remove Manual Transaction

  • Value: Remove Manual Transaction

Step-by-Step Instructions

Note: The steps provided must explicitly refer to actions taken within the Dictionaries module, using generic actions like 'View,' 'Add,' 'Edit,' and 'Delete' a record.

How to View a Record's Status

To check the status of existing dictionary items, navigate to the Dictionaries module and locate the specific dictionary category (e.g., "Crm Rating" or "Priority"). Click the "Edit" or "Items" button associated with that category. The resulting list will display all items, showing their current 'Name' and 'Is Active' status, allowing you to verify which options are currently available to users.

How to Add a New Record

1. Open the Dictionaries module.

2. Locate the relevant dictionary category (e.g., "Inquired Via") in the main grid.

3. Click the "Items" or "Edit" button to open the list of values.

4. Click the Add button.

5. Fill in the Item Name (e.g., "TikTok Ads").

6. Ensure the Is Active checkbox is selected.

7. Click Save or Submit to finalize the new record.

    

How to Edit an Existing Record

1. Access the Dictionaries module and select the target category (e.g., "Opportunity Type").

2. Click "Items" to view the list of existing records.

3. Locate the specific record you wish to modify (e.g., changing "Service" to "Service Bundle").

4. Click the Edit icon next to the record.

5. Update the Item Name or modify Translations as required.

6. Click Save to apply the changes immediately.

    

How to Delete (Cancel) a Record

1. Navigate to the Dictionaries module and open the item list for the desired category (e.g., "Lead Rejection Reason").

2. Find the record you wish to remove.

3. If the system allows hard deletion (often restricted for data integrity), click the Delete icon.

4. Best Practice: If the record has been used historically (e.g., "Old Pricing" in "Meeting Subtype"), instead of deleting, Edit the record and uncheck the Is Active box. This "cancels" its future availability without breaking historical data.

Hints and Tips

• Preserve System Keys: When editing dictionaries like "Lead Status" or "Phone Subtype," avoid altering records with a defined System Key (e.g., 'new', 'dead'). Changing the display name is safe, but the system relies on the underlying key for automation logic.

• Deactivate Instead of Delete: For dictionaries like "Campaign" or "MarketingDetailSource," historical data is crucial for reporting. Never delete an old campaign source; simply uncheck Is Active to hide it from new entries while keeping old reports accurate.

• Consistent Naming Conventions: When adding items to "Training Type" or "MarketingDetailSource," maintain a consistent casing and format (e.g., always use "Instagram" vs "instagram" vs “INSTAGRAM“) to ensure drop-down lists look professional and sort logically.

• Language Localization: If your organization operates in multiple regions, always check the Translations tab when adding a new "Document Type" or "Due Date Schema." Adding the local language variant immediately prevents confusion for international staff.

• Dictionaries "Class Duration", "FacilityBookingDuration" and "PersonalTrainingDuration", when adding custom values, ensure that the default values of 15,30,45,60,120,180 are also added back to the dictionary (or only the ones that you currently use).

   

Use Case Examples

Updating Marketing Sources

• Scenario: The marketing team launches a new social media initiative.

• Module Action: An admin accesses the Dictionaries module, selects "Campaign" (formerly MarketingDetailSource), and adds a new item named "Instagram Influencer."

• Outcome: Sales staff can now accurately attribute new leads to this specific source in the CRM.

Refining Lead Qualification

• Scenario: The sales manager wants to differentiate between "Cold" leads and those who are simply "Unreachable."

• Module Action: In the "Crm Rating" dictionary, the admin adds a new item "Unreachable" and edits the existing "Cold" item to clarify its definition.

• Outcome: Improved granularity in sales pipeline reporting.

Localizing Document Requirements

• Scenario: A new club location opens in a region requiring specific ID types.

• Module Action: The admin edits the "Document Type" dictionary to include "Resident ID Card" and adds the local language translation.

• Outcome: Front desk staff see the correct, localized ID options when registering new members.

Standardizing Appointment Durations

• Scenario: The club introduces a new 90-minute massage service.

• Module Action: The admin navigates to "FacilityBookingDuration" in Dictionaries and adds a "90" entry.

• Outcome: The scheduling system now allows bookings of this specific length without manual overrides.

Managing Lead Rejection Reasons

• Scenario: To better understand why leads are lost, management wants to track "Price" specifically.

• Module Action: In the "Lead Rejection Reason" dictionary, the admin adds "Price too high" as a new active option.

• Outcome: Reporting will now highlight if pricing is the primary barrier to conversion, distinct from the generic "Other" reason.

Classifying Phone Interactions

• Scenario: Support staff need to log calls related specifically to billing disputes.

• Module Action: The admin adds "Billing Dispute" to the "Phone Subtype" dictionary.

• Outcome: Call logs can be filtered to identify trends in billing-related support volume.

Adding a New Class Duration:

• Scenario: The gym wants to introduce shorter, high-intensity 20-minute classes.

• Module Applied: Dictionaries (TimeTableDuration).

• Outcome: The administrator adds "20" to the dictionary. Instructors can now select "20 minutes" when creating new timetable slots. If this is the only time set, all default intervals need to be added in.

Tracking Refund Reasons:

• Scenario: Management notices a spike in refunds and wants to know why.

• Module Applied: Dictionaries (UserPosTxDeleteReason).

• Outcome: New reasons "Customer Dissatisfied" and "Accidental Double Charge" are added. Future refunds are tagged, allowing for a detailed report on the root causes of revenue loss.

Localizing Corporate Tax Data:

• Scenario: The gym expands to a new city and signs up local corporate partners.

• Module Applied: Dictionaries (TaxOffice).

• Outcome: The specific local Tax Office name is added. Staff can now correctly assign the new corporate clients to the local jurisdiction for invoicing purposes.

Customizing Member Suspension Status:

• Scenario: The club needs to differentiate between members suspended for bad behavior versus payment issues.

• Module Applied: Dictionaries (UserStatus).

• Outcome: A status "Suspended - Conduct" is created. This allows front-desk staff to immediately see why a member is denied entry, without guessing.

Audit Trail for Transaction Corrections:

• Scenario: An accountant needs to void a transaction that was entered with the wrong date.

• Module Applied: Dictionaries (UserTransactionDeleteReason).

• Outcome: A reason "Incorrect Date Entry" is added. The accountant selects this when deleting the transaction, preserving a clear audit trail for the financial controller.