> For the complete documentation index, see [llms.txt](https://docs.redivis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.redivis.com/guides/administer-an-organization/configure-access-systems.md). # Configure access systems One of the main tasks of an organization administrator is to manage who has access to datasets. Redivis has tools to support any level of complexity in data systems for your restricted data and makes it easy for organization administrators to define, manage, and audit access rules across these various use cases. ## 1. Consider your organization's access needs Do you primarily have public datasets? Should a small group of researchers with access to all datasets? Do you need to gather information from researchers before they use your datasets? Do you have high risk data that can't ever leave the system? Or some combination of the above? Redivis supports access systems for all of these configurations, but you'll want to use different tools to achieve these very different goals. For example, if you have few datasets, you might find that permission groups for bulk managing access rules aren't particularly helpful. Or if you have a small group of researchers who you all know closely, you might not need to set up process-driven access rules through requirements, and can instead grant access to certain researchers on an individual basis. This guide walks through all the tools available to organizations for managing access, but you'll likely want to pick and choose from what's available to meet your organization's specific needs. ## 2. Understand access levels All interactions with data on Redivis require the user to have the appropriate [**access level**](/reference/data-access/access-levels.md) for that action. Ideally your data would be as permissive as possible to allow for the greatest exploration from researchers before they need to start applying for access. Dataset access has five levels: 1. **Overview**: the ability to see a dataset and its documentation. 2. **Metadata**: the ability to view variable names and univariate summary statistics, but not to retrieve any identifiable information or multivariate relationships from the data. 3. **Sample**: the ability to view and query a dataset's 1% sample. This only exists for datasets that have a sample configured. 4. **Data**: the ability to view and query a dataset's tables, and work with them in workflows. 5. **Edit**: the ability to edit the dataset and release new versions. Access levels are cumulative. For example, in order to gain data access you will need to have gained metadata access as well. It's best to make your dataset's metadata as open as possible. This will reveal variable names and aggregate summary statistics, but will not allow researchers to view, query, or export the raw data in any way. Being able to see metadata greatly improves researchers' discovery experience, and allows them to better assess a dataset's utility upfront, and even reduce your administrative workload. If researchers can understand a dataset before applying for access, they'll be submitting fewer access applications to datasets that are ultimately a dead end. *Learn more in the* [*Access levels*](/reference/data-access/access-levels.md) *reference section.* ## 3. Understand available access tools #### **Membership** Anyone wanting to apply for access to restricted datasets in your organization must first be a member. You can configure whether memberships are restricted to certain identity providers, such as your institutional login, and whether they are approved automatically or require administrator review. You also have the option to configure access to datasets to **All members**. #### **Direct access** Permission granted directly to a researcher to instantly gain access to a dataset at a specific level. Researchers can also request access to datasets with this configuration. Example usage: a dataset that will only be shared with a small number of people who are already known to administrators. #### **Member requirements** A form for members to fill out. This can be set to require approval from an administrator or be automatically approved. It can also have an expiration date. These are global to your organization and when assigned to multiple datasets a user will only fill it out one time. Example usage: a demographic form gathering researcher personal information, or a data use agreement signed PDF. #### **Project requirements** Similar to requirements, but instead of each user needing to fill them out individually, only one requirement needs to be completed for the entire project, which can include multiple researchers. A single researcher may also belong to multiple projects. Each project working with the dataset will need to fill out its own project requirement, and any queries or exports of the data will be tied to that project. Example usage: a funding proposal for a research project. #### **Data export restrictions** A rule defining that a dataset can only be exported to a specific export environment, as configured on the Administrator panel **Settings** tab. Example usage: limiting exports to a specific server environment *Learn more in the* [*Configuring access*](/reference/data-access/configuring-access.md) *reference section.* ## 4. Create requirements If you want to work with requirements, you'll want to get started making them and planning out how they will work across datasets. Perhaps you want one requirement for all members to fill out about their field of research, which is necessary to gain access to any of your datasets, but another 4 requirements with different data use agreements that will apply only to their specific datasets. To get started, go to the **Requirements** tab of the administrator panel and select **New requirement**. You will need to start by choosing if the requirement will be a Member requirement or a Project requirement.
You can use the form builder to collect various information, including standard form responses, file uploads, and e-signatures. *Learn more in the* [*Requirements*](/reference/organizations/requirements.md) *reference section.* ## 5. Create permission groups A permission group is an access configuration that can be assigned to multiple datasets and managed centrally. You don't need to use permission groups, and it might not make sense to do so if each of your datasets has a different access configuration and you aren't using requirements. However, if you have any overlap between datasets and want to enforce consistency or use requirements, you'll want to make one. To get started, go to the Permission groups tab of the administrator panel and select **New permission group**.
This interface requires you to set an access paradigm for each access level of the dataset. You can set the overview access level to be public, the metadata access level to be available to all members, and data access level to be direct access. This results in you having to directly grant access to users, or respond to their requests for access. Or perhaps you'd like to set the overview access level to public, and assign multiple requirements to the metadata and data access levels. This means anyone who is approved for all requirements will automatically gain that access level. You can assign data export restrictions here and choose whether you want to manage access to the dataset's sample (if it exists) differently than the full data. {% hint style="warning" %} If overview access to a dataset isn't public, non-approved users will not be able to see the dataset or its name in any way. In some cases, this may be the intended behavior, but remember there will be no way for researchers to apply for these datasets. For these hidden datasets, an administrator will need to first explicitly grant overview access before researchers can view the dataset and request further access. {% endhint %} *Learn more in the* [*Permission groups*](/reference/organizations/permission-groups.md) *reference section.* ## 6. Assign access permissions to datasets Finally you'll need to apply these access permissions to actual data! Open any of your datasets and select **Configure access.** This configuration setup looks very similar to configuring the permission group. You can either create a custom configuration here or assign this dataset to one of the **Permission groups** by choosing the desired group from the dropdown menu in the top right corner of this modal. This is also where you manage any direct access requests for the dataset.
## 7. Verify your setup As an administrator of this organization, you will have access to all datasets no matter what your access configuration is or what requirements you have filled out. We recommend checking that your access system works as expected by either looking at a dataset while you are logged out, in your browser's incognito mode, or by making a second Redivis account using a different email address that is not linked to your administrator account. ## Next steps **Grant access to data** You have some shiny access systems, but they won't work if you don't approve user requests for access. *Learn more in the* [*Grant access to data*](/guides/administer-an-organization/grant-access-to-data.md) *guide.* #### Expand your reach If you are part of a larger institution, [contact us](https://redivis.com/contact) about getting an institution-wide Redivis page to help users discover your organizations and datasets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.redivis.com/guides/administer-an-organization/configure-access-systems.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.