When you configure a Security Role within the system (see page 19 for how to add a new Security Role), you will see a list of permissions that you can configure as you wish. This allows you to specify exactly how each user will be permitted to interact with the system. It’s helpful to think of permissions in two layers, one that is relatively simple, and one that is more complex. The first (and simpler) layer is comprised of all of the underlying Customer Experience Management (CXM) actions that you can grant or deny, such as Create, Read, Update, and Delete (CRUD). The second (more complex) layer folds in business logic and includes permissions around Processes, Instruments, and Issues. These permissions are enforced through an “access aggregate,” in which ARMATURE Fabric takes data, puts it together with business logic, and presents it back to the user (e.g. Instrument Responses).

Permission Options: Allow, Deny and N/A

When you are establishing permissions at the Security Role or Security Group level, you will see three options: Allow, Deny, and N/A. The default option is N/A, which is a neutral setting; ARMATURE Fabric ships with N/A for all permissions, and allows you to opt in to allow or deny for each action.

If there is a permission you definitely do NOT want a user role to have, it’s important to select Deny at the time of Security Role setup.

Permission Precedence

Due to the many security options available in ARMATURE Fabric, it is possible that conflicting permission settings might apply to a particular user. For example, if a user belongs to more than one Security Group—each group with different Security Roles defined where the same option may have been set to “Deny” in one role and “Allow” or “N/A” in another, the system needs to determine which permission(s) should be given precedence. The rules are as follows:

• “Deny” permissions take precedence over “Allow” permissions
• “Allow” permissions take precedence over “N/A” permissions

Permission Categories

Permissions are grouped by category, and the categories are listed on the right side of the screen. The categories are as follows:

• CXM: This module includes the data and features related to Organizations, Programs, and People.
• Document Management: This module allows you to document, search for, capture, and organize versions of all of the content pieces and collateral that live in your system. It also encompasses publications and reports.
• Entity Management: This module can be used to create and extend custom business objects without the need for custom code. Entity Management includes email, comments, and notes.
• Fabric: This category is internal to ARMATURE; do not manipulate.
• Notification Management: This category is internal to ARMATURE; do not manipulate.
• Process Management: This module includes the elements associated to process/workflow management, including process definitions.
• Quality Management: This module includes all aspects of Instrument creation, assignment, response, and review, including questions, ratings, and standards.
• Security: This module covers all system security settings.

Common Permission Actions: CRUD

Many of the same permission sets repeat throughout the application. The most common actions are referred to by the acronym CRUD, and are defined below:

• Create: Allows you to grant users permission to create new [ENTITY] in the system (such as Organization, Person, etc.). You can also deny this permission.
• Read: Allows you to grant users permission to read [ENTITY] in the system. They will be able to view [ENTITY] but will not be able to update. You can also deny this permission.
• Update: Allows you to grant users permission to update [ENTITY] in the system. You can also deny this permission.
• Delete: Allows you to grant users permission to delete [ENTITY] in the system (such as Organization, Person, etc.). We strongly discourage you from allowing anyone to delete anything in ARMATURE Fabric.

Additional Permission Actions

CXM Permissions

Application

Applications refer to the application entity that manages a Customer’s accreditation application. It triggers the start of a lifecycle and allows you to tie Application Instruments, Certificate Types, Accreditation Types, and Decisions back to the Application entity.

ApplicationCertificateType

The ApplicationCertificateType is a type of certification that your Customers can apply for that is associated to the Application.

CertificateType

The CertificateType is a permission that relates to Applications, and is generally reserved for Admin users (occasionally Staff as well). The CertificateType permission allows you to create a library of certificate types. 

Certification

The Certification permission ties back to Applications, and allows you to decide which roles are allowed to create, delete, read, and update certifications.

CertificationDecision

The CertificationDecision permission also ties back to Applications, and allows you to decide which roles are allowed to manage certification decisions.

Groups

For the purposes of permissions, “Groups” does not refer to Security Groups (which is a menu item to the left of Security Roles on the top menu); groups in this context refers to the groups that you see in the CRM portion of our system, as shown below:

OrganizationDecisions

If you go into any Organization in the system, you have a Decisions tab that allows you to render decisions. This permission allows you to grant users the power to do so.

OrganizationProgramDecisions

The OrganizationProgramDecisions permission is set for decisions against Programs instead of Organizations, but the concept is the same as in OrganizationDecisions.

OrganizationPrograms

Grant/deny permission for Staff to add programs to an organization. This is helpful, as it’s common for organizations to have dozens of programs. When you assign one of the programs from your programs directory to an organization, it becomes an “OrganizationProgram” (i.e. an instance of that program within an organization).

Organizations

Grant/deny permission to create/update/manage organizations in the system.

Part

Grant/deny permission to create/update/manage parts in the system.

People

Grant/deny permission to create and update people in the system.

PersonDecisions

Grant/deny permission to render a decision against a person in the system. This applies to Person Certifications.

Programs

Grant/deny permission to create and manage the programs directory. This permission is generally limited to an Admin and a few Staff members.

Requests

Applies to inquiries and complaints; grant/deny permission to Create, Read, Update, and Delete requests.

Scope

Part of the Applications functionality, the scope permission allows you to grant/deny permission to segment certificate types, application types, and manage how people get certified.

System

This permission is for internal ARMATURE use only; ignore.

Teams

Teams are pre-defined groups with roles. ARMATURE Fabric allows you to create teams that you can then decide to apply to Instrument Responses, Processes, etc. 

TeamTypes

The TeamTypes permission corresponds to Team Types in the main menu, as shown below:

NOTE: This permission does not tie into security. We recommend that you deny this permission and leave it to Admin users to determine team types.

Document Management Permissions

Documents

This permission allows you to decide who has the ability to create and modify documents in the system, along with locking, controlling, and sharing documents.

Folders

Within documents, you can grant users permission to create, modify lock, read, modify control, update, and delete folders.

Publications

You can grant users permission to create publications that can be used throughout the system. We encourage some restriction around this. Otherwise, you might end up with 17 variations of the same publication because people wanted to change a word or two, which would cause version control headaches.

Report

Report permissions should be opened up to Staff, generally. In order to create reports, you first need a shaped data source, which has its own permission, shown below:

ReportTemplate

The report template permission allows you to grant/deny users permission to create report templates in the system. We recommend restriction around this permission, as many Staff users do not want or need to be able to create and update report templates.

ShapedDataSource

Shaped data sources are the building blocks of reports, and they are generated from data sources. We recommend opening this permission to an Admin or two and restricting everyone else.

System

ARMATURE internal permission; ignore.

Process Management Permissions

Process

The process permission allows you to grant users the ability to read, update, delete, and bulk assign processes. You may also allow them to send emails pertaining to processes and start processes.

ProcessDefinition

The process definition is the framework for a given process. We recommend restricting process definition permissions to Admin users, while opening up process permissions (scheduling, etc.) to Staff.

System

This permission is for ARMATURE internal use only; ignore.

Quality Management Permissions

DefaultFinding

This permission relates to canned findings. If your system contains a library of default findings, you can grant/deny users permission to create, read, update, and delete these findings.

Defective Part

Defective parts in quality management are similar to Issues in accreditation and certification, so it’s best to think of a defective part as an issue about a part. Defective part permissions allow you to grant/deny users access to managing this aspect of quality.

Inspection

Inspections are the quality process around parts. When you have a problem with a part, you register it as a defective part and you can run a process to remediate it. Inspections include disposition, outcome, and whether or not it goes back to the vendor, etc. and the permissions in ARMATURE Fabric allow you to grant/deny users access to these actions.

Instrument

The Instruments permission allows you to grant/deny access to the Instrument Builder. We recommend limiting who has permission to create Instruments in the system.

InstrumentResponses

This permission applies to scheduling a published Instrument. Most Staff users need this permission.

InstrumentReview

You’ll notice that there is no “create” action under this permission. This is because an Instrument Review needs to be created in the context of an Instrument Response, and cannot be created as a stand-alone entity. There is a “review” permission on the Instrument Response that allows you to grant/deny this action. 

Issue

This permission allows you to grant/deny users the ability to create and manage issues in the system. The issue mode when it’s initially entered (business logic) affects whether the representative can see it and needs to triage it.

Library

The library in ARMATURE Fabric is for the entire Instrument part. (As a reminder, a “part” is a white box in an Instrument; basically a data collection question.) The library can include criteria parts, content parts, table questions, form questions (any questions). In addition, you can library the settings on the parts: allow comments, allow issues, allow documents, etc. so that you can reuse the entire part, not just the question inside the part.

Question

This permission should be limited to the people who have the responsibility of managing Instruments. We don’t have the ability to create questions directly in a library.

RatingConfiguration

This permission should be limited to the people who have the responsibility of managing Instruments and Standards.

Standard

Additional option to publish standards:

System

This permission is for internal ARMATURE use only; ignore.

TableQuestion

Table Question permissions should be set the same as Questions (above). For example, you want users who have permission to create questions to have permission to also create table questions.

Security Permissions

The permissions in this category are Admin functions that should be restricted. The security permissions allow you to create Security Users, Security Groups, and Security Roles. We recommend approaching security by first determining who the players are in your system: you’ll have an Admin or two, and you’ll have Staff. Are there Staff members who should have more access than other Staff? If that’s the case, you’ll have multiple Staff roles. (Refer to our Security User Guide for more information on Security.)

Customers

This permission is for internal ARMATURE use only; ignore.

Modules

This permission is for internal ARMATURE use only; ignore.

SecurityGroups

This permission allows Administrators to manage Security-related groups and the assignment of roles to groups.

SecurityRoles

This permission allows Administrators to manage Security Roles and the assignment of permissions to these roles.

System

This permission is for internal ARMATURE use only; ignore.

Users

This permission allows Administrators to manage user setup. Administrators can assign Security Groups and Security Roles to the user, which control what the user can access. It also allows the Administrator to reset a user password.

Trusted Contacts

The endpoints that relate to Trusted Contacts do not require permission settings. For example, if you are the Trusted Contact for an Organization, you don’t need to be granted the “Organization Update” permission. Because you are using the system in the context of that Organization and you are Trusted, you don’t need any permissions in the system to have access to that entry point. The permissions you need as a Trusted Contact are inherited.

You can manage your external users and their permissions via Trusted Contact permissions (go to SETUP à CUSTOMER SETTINGS to view the access assigned to Trusted Contacts).