The demo chooses to use only Veil2's role tables for its roles implementation. This makes things very simple, but may be unhelpful as an example. The author apologizes but there are some things you will have to do for yourselves. Look for STEP 8 in the file demo/veil2_demo--&version;.sql. If your existing system has roles of some sort that you wish to keep using, you are going to have to find a way to integrate them with the veil2.roles table. There are essentially three options: This is likely to be a reasonably complex process. You are going to need: an id mapping mechanism; Your existing role keys are not going to work with Veil2, so we will need a way to map your role keys with Veil2's role_ids. Note that you need to keep the range of role_ids as small as possible in order to keep their bitmap representations small. You will need to create a table that maps between veil2.roles and your database's roles table(s). Use foreign key relationships and triggers to ensure that your mapping table is kept in step with your existing table and the veil2.roles table. For some examples of how the triggers can be constructed take a look at the demo. In particular the way that the demo's parties table is linked to veil2.accessors. Whether this will work, will depend on the semantics of your existing role implementation. If they are similar to Veil2's role semantics, this may work. You will have to do some careful thinking about this. In this option, we replace your roles implementation with that from Veil2 but make it look like your existing implementation is still in place. The key to this is to use views and instead-of triggers to make the Veil2 table function in the same way as your existing table. As with the previous option, this will require some serious thinking, but it will probably give you a simpler system than the previous option. Roles and privileges are complex enough without adding an extra level of redirection. This is conceptually the simplest approach but the amount of work will very much depend on your existing system and its needs. The demo chooses to use Veil2's implementation of roles, rather than integrating any existing role implementation. Since the demo was built with Veil2 in mind this makes a lot of sense as it keeps the implementation much cleaner and simpler. If you are building a new system from scratch, this should be your preferred approach. If your application has user-level roles (roles that are assigned to users), you may be able to re-use them. You will probably not have function-level roles however, and you will need to at least create a minimal set of these. The minimal set of user-level roles should be enough to give you 2 or more pieces of functionality that you can then use to test your access control mechanisms. To these roles, you will assign privileges by creating records in veil2.role_privileges. You will then need to create role to role mappings, making your function-level roles available to your user-level roles. You will do this by creating records in veil2.role_roles. As with privileges, you should keep the range of role_ids as small as possible, allocating them contiguously and re-use ids for records that get deleted. Note that if you have decided to use role to role mappings in anything other than the global context you will need to define your mappings in each of those contexts. Your role names may also need to be customized for those contexts. This is shown in the demo; look for the text STEP 8. Any time that role to role or role to privilege mappings are updated, all materialized views and caches must be updated. Since these mappings are managed exclusively from Veil2 tables, all the necessary triggers to refresh our materialized views are already in place.