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’. ‘Agents’, ‘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.
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:
- Access to Specify components (like the Query Builder, Workbench, or Schema Configuration).
- Access to data tables, including permissions for Create, Read, Update, and Delete (CRUD) operations.
Introduction to Permissions
Security and Accounts Documentation
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?
This is a key difference from Specify 6. The Specify 6 security model included features for marking individual ‘Collection Object’ or ‘Locality’ records as “sensitive” to hide them from certain users or web export.
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. |