Specify's Organizational Model and User Accounts for Multiple Collections

[Grant]

This guide explains how data is shared across collections and how to access data from different collections. It breaks down different user scenarios, explains what permissions they might have, and describes what access and responsibilities they would have.

Overview

Specify supports data from multiple collections within a single database. For example, specimen records for fish and for birds are combined within the same data tables of a single database. For institutions with multiple collections, this storage model enables, but does not necessarily grant, access to data across multiple disciplines for most users. Users typically have login and access privileges only for their collection’s data.

Access to data across collections, disciplines, or divisions is an important capability for museums with centralized registration, accession, or conservation activities. It also allows others with a legitimate interest in the institution’s complete holdings, such as research directors, to analyze and report on the institution’s entire holdings.

In Specify, there are data tables and data entry forms for entering ‘Institution’ and ‘Division’-level information, where a ‘Division’ usually (but not always) represents a single taxonomic discipline. Each ‘Division’ or ‘Discipline’ may have multiple collections; for example, Ichthyology may have a voucher and tissue collection, and Ornithology may have voucher, tissue, and egg ‘Collections’.

Figure 1 – Specify’s Institution, Division, Discipline and Collection hierarchy

How are Specify Data Shared Across Collections?

For a Specify user, data elements have visibility or “scope” relative to other data elements and with respect to the administrative context of a ‘Collection’.

The figure below shows an overview of the “scope” of various records in Specify. As we move left to right in the figure, the scope is reduced. The data types shown in the ‘Discipline’ column are scoped to that ‘Discipline’, available to all ‘Collections’ defined under it. All ‘Collection Objects’ in those ‘Collections’ can access those data items.

Put another way, all ‘Collections’ within a ‘Discipline’ share the same ‘Taxon’ Tree (or multiple taxon trees), ‘Localities’, ‘Collecting Events’, etc. One level down, each ‘Collection’ has its own set of ‘Collection Objects’, ‘Preparation Types’, and ‘Pick Lists’.

Given the example in Figure 1, for the Ichthyology ‘Discipline’, both the Wet and Dry ‘Collection’ would share a ‘Taxon’ Tree, ‘Geography’ Tree, ‘Agents’ (e.g. collectors, authors, annotators), etc.

The Wet ‘Collection’ would have its own set of ‘Preparation Types’ and ‘Pick Lists’, which would be different from the Dry ‘Collection’’s. While these can be different, there is no barrier to duplicating values across ‘Collections’, ‘Collecting Events’, ‘Collecting Trips’, and ‘Localities’ are all scoped to the ‘Discipline’.

For a complete, detailed list of which tables are scoped to which level, please see our full Institutional Scoping in Specify documentation.

Specify Institutional Scopings

This guide explains how institutions are scoped in Specify. It provides an example collection hierarchy, the table scoping hierarchy, and explains the pros and cons of one collection vs. multiple collections. Specify supports data from multiple collections within a single database. For example, specimen records for fish and birds are combined within the same data tables of the database. For institutions with multiple collections, this storage model enables but does not grant access to …

Security and Data Access in Specify 7

Specify 7 uses a role-based access system that provides granular control over what users can see and do. Administrators (like an Institution Administrator or Collection Administrator) create Roles (e.g., “Curator,” “Data Entry,” “Student Volunteer”) and assign specific permissions to them.

These permissions are additive. By default, a new user has no permissions. A user is then assigned one or more roles, and their total permissions are the sum of all permissions granted by those roles. For example, you could assign a user a “Data Entry” role that grants access to ‘Collection Object’ forms and a “Georeferencer” role that grants access to the ‘Locality’ table.

This system controls:

1. Access to Specify components (like the Query Builder, Workbench, or Schema Configuration).
2. Access to data tables, including permissions for Create, Read, Update, and Delete (CRUD) operations.

Introduction to Permissions

Specify Permission System Introduction

Introducing the Role-Based Access System in Specify 7 Specify 7.7 (July 2022) introduced a new, role-based access system for granting privileges to user accounts to access Specify components, data tables and fields. The new permissions system provides considerable flexibility for a collection institution to align data security policies with Specify functions to reflect institutional preferences for how curators, collection managers, researchers, students, guests and other kinds of users process …

Security and Accounts Documentation

Security and Accounts

This guide covers the Security and Accounts system and explains how to define user roles and assign them. [!caution] Before You Begin It is highly advised that you read and understand Specify Institutional Scopings before customizing user access and permissions. Security and Accounts The Security and Accounts system in Specify 7 is a comprehensive Role-Based Access Control (RBAC) framework designed to give institutions precise control over data access and user privileges. It a…

Specify User Scenarios

User Scenario	Assigned Roles (Example Combination)	Description of Access & Responsibilities
1. Institution Admin	Institution Admin (Status)	This user is a “super administrator” with unrestricted power. They have all permissions in all collections. They can create/delete collections, manage all user accounts, assign Collection Admins, download database backups, and access institution-wide settings. This role is for top-level technical staff only.
2. Collection Manager	Collection Admin, Security Admin	This is the primary manager for a single collection. They can manage user accounts and assign roles for their collection. They have full data access, can edit forms (Edit Forms), manage Pick Lists, and oversee all collection activities. They are the admin within their collection, but not for the whole institution.
3. Lead Curator	Full Data Access, Edit Taxon Tree, Edit Forms and Global Preferences, Run Queries	This user has full “power-user” access to the data and its structure. They can perform all data operations (Create, Read, Update, Delete), manage the Taxon tree, and configure data entry forms and global preferences. They typically do not manage user accounts.
4. Data Entry Staff	Full Data Access (minus Delete), Full WorkBench access, Bulk Attachment Import, Run Queries	This user is focused on day-to-day data input and editing. They have permission to add and edit records, use the WorkBench for data uploads, and run queries. They cannot delete records (a common safety restriction) or change the database structure (forms, pick lists).
5. Registrar	Manage Interactions, Full Data Access, Print Reports, Run Queries	This user is specialized in managing transactions. They have full data access, with a specific focus on the roles needed to create, update, and track Loans, Gifts, and other Interactions. They can also print reports (e.g., loan invoices) and run queries.
6. IT / Security Auditor	Inspect Audit Log, Security Admin, Read-Only Access	This user is responsible for system oversight, not collections data. They can view the Audit Log to track user activity and view security configurations (Security Admin), but they do not have permission to modify any collections data.
7. Student Intern	Read-Only Access, Run Queries, Create Data Sets	This user has a limited, “safe” role. They can look up any data and run queries to build Record Sets (e.g., for a class project or research task), but they cannot add, edit, or delete any records in the database.
8. Visiting Researcher	Read-Only Access, Run Queries, Export Data, Print Reports	This is a typical “guest” account. The user can search and explore the collection’s data, run complex queries, export datasets for their research, and print reports (like labels). They cannot make any changes to the data.

Access To Multiple Collections

The Specify 7 role-based system fully supports users who need different levels of access across multiple collections.

Because roles are assigned to a user per collection, a single user account can have different roles for each collection they are a member of. For example, the same user could be a “Collection Administrator” for the Botany Collection but have a read-only “Guest” role in the Entomology Collection, all while using a single login.

Who Can See My Collection Data?

When a user logs in to Specify 7, they select a single ‘Collection’ to work in. This sets the “context” or “scope” for their session.

All searches and queries are constrained by this scope. For example, if you run a query for ‘Collection Objects’, it will only return results from the ‘Collection’ you are currently logged into. If you search for an ‘Agent’, it will search all ‘Agents’ within the current ‘Discipline’ (since ‘Agent’ is scoped at the ‘Discipline’ level).

Your ability to see or interact with any data is determined by the permissions granted to your Role for that specific collection.

What About Sensitive Data?

Access control in Specify 7 is handled at the table level. For example, you can use a Role to prevent a user from reading, updating, or deleting any data in the ‘Locality’ table, but you cannot use it to hide specific ‘Locality’ records while showing others.

Summary

Specify 7 enables a single database to house all the data for an institution, organized by ‘Institution’, ‘Division’, ‘Discipline’, and ‘Collection’. The scope of data (e.g., ‘Taxon’ at the ‘Discipline’ level, ‘Collection Object’ at the ‘Collection’ level) determines how it is shared between collections.

A powerful role-based access system provides secure, granular control over user permissions. Access is granted by assigning one or more Roles to a user for each ‘Collection’, and these permissions are additive. This flexible system replaces the rigid user “groups” from Specify 6.

Frequently Asked Questions

Question	Answer
‘When I search can I see ‘Collection Objects’ from other collections?’	No. ‘Collection Objects’ belong to only one ‘Collection’. When you log in, you choose a ‘Collection’, and all your searches for ‘Collection Objects’ are limited to that collection.
‘Can I assign the same ‘Agent’ as a Collector in two different ‘Collections’?’	Yes, as long as both ‘Collections’ are in the same ‘Discipline’. The ‘Agent’ table is scoped at the ‘Discipline’ level, so all ‘Collections’ in that ‘Discipline’ share the same list of ‘Agents’.
‘When I log in do I have the same permission for every ‘Collection’ within a ‘Discipline’?’	Not necessarily. In Specify 7, permissions are assigned to your user account per collection. You could be a “Collection Administrator” in one collection and have a read-only “Guest” role in another, even if both ‘Collections’ are in the same ‘Discipline’.
‘Can I share my ‘Taxonomic Tree’ with the teaching ‘Collection’?’	Yes, if both the “main” ‘Collection’ and teaching ‘Collection’ are in the same ‘Discipline’. The ‘Taxon’ tree (‘Taxonomic Tree’) is scoped at the ‘Discipline’ level.
‘Can a Guest user create a report to show all of the ‘Collection Objects’ in a ‘Collection’?’	This depends entirely on how you configure the “Guest” role in the ‘Security and Accounts’ panel. If you create a “Guest” role and do not grant it permission to execute reports, then no. If you do grant that permission, then yes. You have full control over what each role can do.