We use table-driven custom roles in our budget reporting system and other systems. We store the active directory user login name as a custom field in our primary employee table (we are not yet fully integrated to Active Directory). We load parameter list values from a call to a stored procedure that first converts the domain login name (CURRENT_USER) to an employee ID, then does a lookup on that employee ID in the custom role tables to find which account numbers that employee's role is permitted to access. We return those account numbers out of the stored procedure which is then used to load report parameter 'Accounts'. No 'extra' tables are required.

We use this same model in all report scenarios where custom filtering based on user is required.