Skip to content

Getting Started – Core Data & Permissions

This guide is a task-oriented walkthrough for setting up maXzie. Unlike the user manual, which describes the individual menu items, it takes you through the first setup steps in a sensible order and links several menus into a single process. For detailed questions about individual menus, please refer to the user manual.

Before you begin: background configuration

Section titled “Before you begin: background configuration”

Some of your system’s basic settings are already defined in the background and cannot be changed via the interface. However, they directly affect how individual input forms look and which options are available there.

If you have not already done so, coordinate this background configuration with your maXzie contact at the beginning and clarify any open points. This ensures that the system fits your company and compensation structure right from the start.

In the following, we point out briefly at the relevant places whenever a step depends on such a background configuration.

The setup follows the first menu items from top to bottom. These form the area for the basic configuration of the company and the compensation structure. Start with the core data, because all subsequent steps build on it: first create employees, then structure them into groups, then assign permissions.

In the Employees menu, use the plus button to create an entry for each person. Set the salutation, first and last name, language and the payout currency.

Note the order within the form: the employment history only appears after the currency has been selected. In the employment history, you set an employment status (e.g. Employed) from a given date and then enter the annual target salary and the variable portion. Across several time periods, you can also anticipate later changes such as salary increases.

Between the address and the language, customer-specific fields may appear in the employee form. They are part of the background configuration and can, on the one hand, simply hold additional core data information.

Above all, however, they serve as technical keys, for example for a personnel number, ADM number or territory assignments. These keys are used to map data from external systems to the maXzie employees (when importing into maXzie) and to assign the calculated payouts back to the correct people in payroll accounting (when exporting from maXzie). Maintaining these fields carefully is therefore the basis for a smooth data exchange with adjacent systems.

In the Groups menu, create your teams and assign a name. Under Members, add the individual employees.

Take care to distinguish between two concepts that are easily confused:

A membership means belonging. If you add a group as a member of another group, its employees become transitive members of the parent group. This is only correct if the parent group should actually contain these people.

A relationship, on the other hand, represents a role, such as who leads a team. To link a manager to a team, for example, you do not add this person as a member, but create a row in the Relationships section with the relationship type and the person concerned. The relationship is stored in the respective group and is then available when assigning permissions.

Rule of thumb: if someone should be part of the team, use Members. If someone should have a role for a team (leading, payroll), use Relationships.

Permissions are created as rules via the plus button and read like a sentence following the pattern Who? → Has permission? → For what?:

  • Who?: This determines who receives the permission – an individual employee, a group or all.
  • Has permission?: This is where you select the permission. The permissions are tiered into manage and view, whereby a permission to manage always includes the permission to view.
  • For what?: This determines whose data the permission applies to. The option group with relation is particularly noteworthy: it ties the permission to a relationship type rather than to specific people. This is exactly where the relationships named in Step 2 gain their meaning.

The advantage of this group-based approach: the rule automatically applies to every person who holds the corresponding role in any group, and only ever to the members of that specific group. If managers or team structures change, the permission does not need to be touched.

Example rules from a typical setup:

  • To allow every manager to manage the core data of their team:
    • Who? = All
    • Has permission? = manage core data
    • For what? = group with relation > Manager.
  • To allow payroll accounting to manage the payouts of their team:
    • Who? = All
    • Has permission? = manage payouts
    • For what? = group with relation > Payroll accounting.
  • To allow managers to view the evaluations of their team:
    • Who? = All
    • Has permission? = view evaluations
    • For what? = group with relation > Manager.