Authorisation replication to another environment

Via authorisation replication you can copy the groups, users and authorisation from one environment to the other. This is a fast method for copying the configuration of the authorisation to another environment.

Description

You can use authorisation replication, for example, if a second environment is created for testing purposes. An accountant can also create several environments for customers for which he performs the administration. The environments must, however, relate to the same product, so it should, for example, concern two ERP environments or two Small Business environments.

Example:

An accountant's office uses an environment in Profit for its own administration. In addition, it also has an environment per customer for which it performs the administration, which are the environments OmgKL001, OmgKL002 to OmgKL100.

A new employee enters employment and will be responsible for certain tasks in the environments OmgKL001 to OmgKL004. You add the user to the OmgKL001 environment and set the authorisation. You then replicate the authorisation of environment OmgKL001 to OmgKL002, OmgKL003 and OmgKL004.

Replicated data

The following rules apply when replicating the authorisation to another environment:

Authorisation type

Replication

Reason

New users, groups and rights

Yes

If users, authorisation groups or rights of a user or a group are present in the source environment but not in the target environment, they are added to the target environment with the same properties.

If, for example, a new user with all the rights is added to the source environment, this user also has all the rights in the target environment after replication.

Changed users, groups and rights

Yes

Users, authorisation groups and rights already present in the target environment are overwritten by the corresponding data from the source environment.

If, for example, a user is blocked in the source environment, the user is also blocked in the target environment after the replication.

Deleted users

Yes

If a user is deleted from the source environment, the user is blocked in the target environment, because there may still be references to the user.

Deleted groups

Yes

Groups that do not exist in the source environment, but do in the target environment, are deleted from the target environment once the users have been deleted from the group in question. Groups cannot always be deleted, because related data may be present. In that case the users are deleted from the group, but the group continues to exist.

Example:

If Groep1, to which gebruiker1 is linked, is deleted from the source environment, gebruiker1 is unlinked from Groep1 in the target environment, after which Groep1 is deleted.

Deleted rights

Yes

Rights assigned to a user or group in a target environment, but not assigned in the source environment, are deleted from the target environment for the user or group in question.

Fill groups based on selection

No

If Profit indicates that a group must be populated based on a selection, the definition of the selection is not replicated. However, the result of the selection (the users linked to the group at that time based on the selection) is copied.

Rights to custom tabs and custom fields.

No

As separate custom fields and tabs can be defined per environment, the rights defined for these are not replicated.

Data filter

No

Data filters are not replicated, because they usually relate to a specific (administration) environment.

Microsoft Office authorisation (AFAS Online)

No

See Set up a user with a Microsoft Office licence (AFAS Online)

You cannot change user codes using the authorisation replication.

Procedure