Roles are configured by setting an Association Type to be a "Role".  This Help Resource demonstrates how to configure an Association Type to be a Role and then uses that Association Type in a working system to demonstrate the purpose of "Role" Association Types.

Setting An Association Type to be a Role

Log into Object Modeller and navigate to the Tools tab and Association Type Manager. In the example below we have already created an Association Type called "Boss of".  It will be used to associate "Contacts" to a "Company Organisation" - as its' Boss(!).  Consequently the contacts who are associated to an organisation as "Boss of" must be able to view and edit its details.

We now add the Association Type to our Contact Object type, and create a rule to the "Company Organisation" object type;

Here it is complete, meaning it can be used in the XPOR administration page.

So if we now log into the back end of the website and create a Company Organisation we can set its' Boss Of to be a selected Contact

In fact there are a lot of Company Organisations - inside a Folder.  Each Company Organisation has a Boss and we would like each Boss to be able to Edit his Organisation details.  We could achieve this in a number of ways;

1. We could manually set individual permissions on each Company Organisation, for each individual Bossed By contact to have read / edit etc. permissions on the respective Company Organisation.  This would take a long time to set up and would make on going management very difficult.
2. We could manually collect all Bossed By contacts into a new Group - called "Bosses".  We could then add this Group as a permissions set to the Group that contains the Company Organisations, set the required permissions and Inherit them to all child (Company Organisation) objects.  This would mean that each Boss could potentially edit any of the company’s.  So we would control this by providing a grid / query that goes from the logged in User ObjectID through its "Boss of" association type to access ONLY its respective Company Organisation.  This is quicker / easier to manage than the first option BUT means that when new organisations / bosses are added / removed, the Group containing the bosses needs to be edited accordingly.
3. Use the fact that all Bosses have a Role Association to their organisation ...

Role associations can be used as a "virtual" permissions Group.  The big advantage is, that, whenever a a Boss is added or removed from a Company Organisation, the permissions are manged as a consequence.  So we will use Role Permissions. similar to the second Option above, and set them on the Group containing the Company Organisations.  We will then recurse those permissions onto all of the Child objects (Company Organisations).

First thing is to select our object to set its permissions - the Group called "Company Organisations" and select its' Permissions Tab.  Click the Add button and select the Role option;

This will open the usual Select Object, for you to browse and select the permissions Control Container that holds the things that you want to have permissions on this object.

In fact, in this example, you only need to select this group (itself) as it contains all of the Organisations and their associated "Bossed By" contacts.

Having selected this Group object (which is a permissions Control Container) we now have to set the actual Role that we require to be used from this Container.  This opens a second form;

So, the first thing is to select an Object type - we are using the Company Organisation and want its "Bossed By" contacts to have the required permissions.  So we first select Company Organisation from the first drop down.  This will populate the second drop down with the Roles that are set on the Company Organisation object type.

This will add the new Permissions Role |Group to the Permissions table for the Company Organisations group;

Set the required permissions as normal, and recurse them to all Company Organisations;

This will mean that any Contact that has the Role association "Boss Of" to a Company Organisation, will have the set permissions on ANY of the objects in this folder.  So, as with the second option, we will only allow the logged in user to see / edit his own "Boss of" Company Organisation by only listing this specific path on a front end form.

The huge management advantage of this is that when a boss is added / removed as Boss of any of the Company Organisations, the permissions work automatically.