How to manage your users' access rights in bulk with the mobility bundle?

This article provides an overview of the mobility bundle and tag functionality and its use cases.

This article is structured as follows:

  1. What is a mobility bundle?
  2. What are tags?
  3. How to make changes
    1. Default mobility bundle
    2. Non-default mobility bundle
  4. FAQs

Definition: A mobility bundle is the link between a tag and a selection of access policies. It serves to seemlessly combine user provisioning / profile creation and access rights attribution. 

1. What is a mobility bundle?

Mobility bundles allow Izix administrators to assign access rights in bulk at the moment of provisioning/creating users. There are two different types of mobility bundles:

  • Default mobility bundle: At any given time, only a single default mobility bundle can exist. The default mobility bundle will be assigned to all users. It does not require the use of tags. It can be identified with the star on the mobility bundle overview.
  • Non-default mobility bundle: Multiple non-default mobility bundles can exist at a given time. Non-default mobility bundles are assigned through the use of tags. A non-default mobility bundle can have multiple tags.

Each mobility bundle - default or not - includes specific access policies forming the access rights of the applicable user. Importantly, only already existing access policies can be added to a mobility bundle. It is therefore important to first create access policies and relevant allowances before creating a mobility bundle.

2. What are tags?

Tags may or may not be related to mobility bundles. Tags without any relation to mobility bundles do not have any direct impact on the users and their accesses. In this case, they are simply used for categorisation and filter purposes on the profile list.

Example: As administrator you want to easily be able to identify and filter managers. Therefore you create/assign the tag "manager".

Tags are not case sensitive. The use of "manager" or "Manager" will create and assign one tag, it does not create two separate tags.

The system creates a so-called "slug" for each tag which is unique to an organisation. The system does not recognise the difference because it is comparing the slugs (something that is not visible in the product interface). This is to avoid tag duplications.

3. Making changes to mobility bundles

Mobility bundles do not apply retroactively. This means, if a change is made to a mobility bundle (e.g. adding a new access right) it will only apply to users that are newly added (or tagged respectively) after the change was done.

Default mobility bundle

When you want to replace a default mobility bundle with another (new default) mobility bundle, you can do so by disabling the default function. The mobility bundle will then turn into a non-default bundle, hence requires a tag to be assigned to users. If the old bundle has no tags, it does not have any impact on users' access rights. If it is no longer needed, we encourage you to delete it to avoid an accumulation of outdated and unused mobility bundles.

Existing users’ access rights will not be impacted by the above changes (acces rights from the old default mobility bundle wont be removed and access rights of the new default mobility bundle wont be added).

If changes are made to the access rights of the default mobility bundle, these access rights are only assigned to newly added users. Already existing users must be updated manually.

Non-default mobility bundles

When a confirmed profile is tagged, they are granted access rights to all access policies within the linked mobility bundle. The association of access rights as part of the mobility bundle is only triggered when a tag is added to or removed from a user. Thus, a mobility bundle does not apply access rights retroactively.

 

Pro tip: To avoid having user profiles with the same tag but different access rights, remove the tag from the user profiles and add it again. The removal/adding of the tag will trigger the assignment of access rights through the mobility bundle.

4. FAQs

Q: I can assign access policies to users individually, why would I use mobility bundles?

  • The idea of mobility bundles is the simplification of assigning access policies in bulk upon the creation of user profiles. Ideally, the parameters of the access policies as part of a mobility bundle do not change frequently. More frequent changes to a user's access rights (e.g. temporarily assigned/removed access policies) should be managed via the user's profile.

Q: If I change the parameters of an existing mobility bundle (e.g. planning period, allowance policy), will this automatically update all tagged users' access rights?

  • No. Mobility bundles do not work retroactively. Already tagged users' access rights won't be affected. Any users that are tagged after the adjustment of the mobility bundle will be assigned the updated access rights.

Q: Can I manually update the access rights on the profile?

  • Yes. We encourage managing temporary access rights changes via the profile overview. The mobility bundle won't be reapplied to the profile unless the tag related to the mobility bundle is removed and newly added.

Q: What happens if some mobility bundles contradict each other?

  • If the access rights and related parameters of a mobility bundle "A" are in contradiction with the ones of a mobility bundle "B" and the user receives tags related to both mobility bundles, only the firstly assigned mobility bundle is applied. The second mobility bundle will be ignored for this user.

Q: I already have tags but no mobility bundles, hence my tags are not related to any mobility bundle. If I add an existing tag to a mobility bundle, will it update the already tagged users' access rights?

  • No. Mobility bundles do not apply access rights retroactively. Please note that it is still possible to have tags that are not related to any mobility bundle. Such tags serve solely to facilitate the classification of your profiles in the profile overview and do not impact access rights.
Q: I created a new access policy, but it does not appear on the mobility bundle as an option. What may be the issue?
  • It is likely that your access policy has a validity start date in the future. Only access policies that have at least the current date as validity start date will be available.

Q: Can I use the mobility bundle to assign access rights to be active in the future?

  • No, this is not possible. There is no possibility to use a specific start date for the mobility bundle, even if the access policy validity date lays in the future.

Q: How are different mobility bundles assigned as part of user provisioning?

  • If a default mobility bundle exists:
    • Profiles without tags receive only the default mobility bundle's access rights.
    • Profiles with tags receive access rights first from the matching tagged mobility bundles and then the default mobility bundle, in that order.
  • If no default mobility bundle exists:
    • Profiles receive access rights only if their tags match a mobility bundle. Profiles without matching tags will not receive any access rights.