Skip to main content
Insert Banner Message here.



Welcome to Community

Are there reasons to stay with previous model or Dynamic Access Control (DAC)?




  • Official comment
    Patrick McMahon

    Hi Roy,

    Dynamic Access Control (DAC) provides extended security configurations that are based on specific criteria. This criteria is defined by each use case and could contain up to five (5) different picklists or objects to define unique access per user for both objects and documents. The legacy defaulting of roles is limited to system objects only (Product & Country) and cannot be expanded for custom requirements.

    The benefit of enabling DAC is that access can be tailored to the role on either the document or the object record based on your specific requirement. By creating these rules for each user, the system then automatically manages and applies 'groups' the applicable documents or object records. If the document or object record is updated, or if the user role setup record for the user is updated, the system will automatically adjust access as necessary.

    In legacy defaulting, Groups are added to roles and defaulted based on Product or Country, or for all documents contained in that lifecycle. This can only happen, if configured, at document creation or workflow start. If metadata is updated, the user access changes - manual processes to add/remove access is required from an administrative level. The users access is controlled via manual assignment to groups that are aligned with roles.

    In terms of benefits to remaining on the legacy access model, that's more of a process based question, as not all use cases require a granular approach or dynamic updates. An example would be for internal Quality Managers - they will need access to everything and wouldn't require DAC to be enabled, simple group membership would be get the job done. Conversely, the same function can be done with DAC as well by creating a User Role Setup record. It's more of a question around what fits your business model and your administrative requirements.

    The decision to enable DAC should be reviewed with your Veeva Product Advisor to address your specific use case or requirements. 


    Patrick McMahon

  • Lewis Taylor

    Hi Roy,


    I agree with Patrick here in that this is a discussion to have with the customer based on needs. You do not mention which Vault product you are working with here but I have found that the more users you have in the production vault the more DAC seems like the only reasonable option as group maintenance can otherwise become prohibitive.

    One reason I have heard from clients for staying with the old model (which has some validity) is that DAC associates roles to users immediately as the URS is created where as the old model might do this only on workflow participant selection. For example you are sending a document for workflow. With DAC you have 3 users assigned in the approvers role however only one is selected. While the document is in the 'In Approval' state the other 2 non selected users have the same rights as the selected one. This does not happen in the old model if the single participant is selected from a manual maintained group of potential approvers




  • Roy Gazdar

    This is great information, thank you Patrick and Lewis for your insights!



  • Lewis Taylor

    no problems Roy. Just one thing to add to this, if you ARE planning to 'undac' roles it is not a good idea to simply create new roles and remove rights from the standard ones (since you cannot disable those). This approach means you would have "approver" role with no rights and <New> approver role which is not DACed. The issues are:

    • The following tokens are used in notification messages can not be used in future if desired for the new roles
      • ${approver__v}
      • ${reviewer__v}
    • Reports can no longer use the standard “Reviewer”, “Approver” or “QA” etc in a filter, prompt or results column
    • If the standard Reviewer and Approver lookup fields are added as columns to documents lists they will be pointing to the solution roles not the <NEW> ones
    • Filters in library can be used but the user has to know to pick <NEW> Approver and not Approver (for example):

    A better approach is to remove DAC matching rules on the existing role and set all allowed groups to 'all Internal Users' or whatever group suits



Please sign in to leave a comment.

Powered by Zendesk