1. Purpose of this Article
The purpose of this Knowledge Base article is to provide new clients with considerations and options for the initial system configuration of SOLABS QM10. SOLABS QM10 has various options and features as well as client-configurable administrative settings that support use of the system for management of documentation, training and quality events.
Your Sandbox environment, along with Administration Guides and other articles available on the Knowledge Base can be used to explore configuration options. Each section of this article includes links to more detailed articles and user guides related to the topic. Your assigned SOLABS Product Specialist is also available to answer any questions and assist with decisions on your configuration options.
Final configuration decisions are documented using Configuration Templates provided by SOLABS (EC-SOL-001 and UR-SOL-001). SOLABS uses those templates for the initial configuration of your Validation and Production environments. You can then manage updates to the configuration settings going forward.
Use this link to print a copy of this article (links to the other related articles are not included in the printed version). Each section will correspond to the same section in the EC-SOL-001 Configuration template.
Links to related information:
2. Add-Ons, Back-End Configuration Options & Features
2.1 Solution - Add-Ons
SOLABS QM Essentials comes with the following sections, which are therefore mandatory:
- Document Management Section
- Document Control Process APP #P0007
- Audit Management Process APP #P0044
The following are Add-Ons and need to be selected in this section:
- Training Management Section
- Questionmark OnDemand (for Online Assessments)
- Deviation Process APP #P0054
- CAPA Process APP #P0050
- Change Control Process APP #P0052 or #P0036
- Laboratory Investigation Request (LIR) Process APP #P0055
- Pharmaceutical Product Complaints Process APP #P0056
2.2 Solution - General Options and Features
- Number of Login Attempts before Lock – the default setting is 5 tries but you can request another number
- Session Timeout Setting – the default setting is 30 minutes but you can request another time
- The Single Sign-On (SSO) feature is available with Azure AD Premium or OneLogin
- The email address from which SOLABS QM Email Notifications are sent can be configured so that your users recognize the Sender and it has less risk of going to a junk folder
- Password Expiration Period - the default setting is 365 days but you can request another period
Links to related information:
https://docs.solabs.com/hc/en-us/articles/360044630133-Single-Sign-On-solutions-SOLABS-QM
https://docs.solabs.com/hc/en-us/articles/1500007002061-When-do-User-Passwords-Expire-and-Why-
2.3 Document Section
- If you use Office 365 you can enable our Collaborative Review feature
- Options for Document Revision Handling
- For Word documents, you can decide whether you’d like Track Changes to be enabled automatically for the document review cycle.
- SOLABS QM can automatically generate a Change Summary File “Compare File” that will show the reviewers, approvers and trainees the changes between a new version of a document and the previous effective version. It is available as a default but you can choose not to have it.
Links to related information:
2.4 Document Control Process APP
- When a Document Control Process is initiated, it is assigned the next available Unique ID. That Process ID has a default prefix of DOC- but you can choose another prefix if you would like.
- The Document Control Process goes into a Waiting Phase while the related documents are out for Review/Approval and/or awaiting any pre-set Training Completion percentage. By default, the last Waiting Phase will end 5 days prior to the Target Completion Date for the process, after which the Document Coordinator can review and update status as needed. You have the option to instead set the last Waiting Phase to end based on Document Status (when documents are Approved or when any set Training Completion percentage is reached).
Links to related information:
3. System Configurations
3.1 System Configurations
This is where the following company identity information is entered:
- Company Name and Address Information
- Company Logo – print logo, interface logo
- Default Login Page Background
- Preferred Date Format
When setting up PDF Rendering Templates for your documents you can choose to display your company name, address, website URL and logo on Document Cover Pages for some of your Document Types. When determining the level of detail for the address information, think about how it will appear on a printed document or report, and what level of detail would be appropriate.
An Interface Logo can be added to your SOLABS QM environment and will be displayed in the top left-hand corner over the SOLABS QM logo.
A Default Login Page Background can be set for your users.
Links to related information:
https://docs.solabs.com/hc/en-us/articles/360044588534-Changing-the-Date-Time-format-of-SOLABS-QM10
3.2 Task Type Configuration
Specific Task Types are associated with Secondary Tasks for any QM APPs you may have deployed in your instance of SOLABS QM and cannot be changed.
If you would like to use the Task Section to assign any client-specific periodic or ad-hoc tasks to your users, you can create your own Task Types to immediately identify their purpose/use to the assignees.
Links to related information:
4. Roles
There are four types of roles in SOLABS QM - some that are pre-defined with the Core Software or Process APPs and some that need to be defined by the client.
Pre-defined Roles:
System Roles: These roles are pre-defined with the Core Software and are not configurable in the system. These roles are available to assign to users in order to grant them the related administrative permissions.
- SOLABS Document Administrator
- SOLABS Training Administrator
- SOLABS System Administrator
- SOLABS Help Desk
Process Roles: These roles are used strictly for Processes and related Process Task assignments. They are pre-defined and deployed with the related Process APP (Examples: PR_CAPA_Owner, PR_CC_CCC, etc.). These roles are available to assign to users in order to grant them the related permissions in the process workflows.
Client-specific Roles:
- Function Roles: These roles are related to job functions within the organization. They can be used to assign training, to assign privileges for document access and to assign group review/approval tasks for documents.
Functional Roles are typically created for each Job Title in the organization so that they are available as part of an electronic signature for document review/approval or to link to any training that is unique to a Job Title.
However, a user can be assigned more than one Functional Role. This could be considered if people with the same Job Title perform different types of tasks, and may therefore require different types of training. In that case, you could create additional Function Roles for training purposes using a Task-based approach, instead of a Job Title approach – or use both approaches to cover your training needs. A Function Role could also be created and assigned to all users in order to link to employee orientation or onboarding training. Additional Function Roles could be created for each department, and assigned to users in that department, to link to departmental training requirements.
- Security Roles: These roles help determine company structure (Organization, Division, Department, Sub-department) for your users. These roles can be used to assign privileges for document access. Departmental Security Roles are also useful in some types of Reports, such as Training Compliance by Department.
Users can have multiple Security Role assignments to define their location in the organization.
Security Roles cannot currently be used to assign departmental training or for departmental Review/Approval workflows. If those are needs for your organization, consider creating additional Function Roles to meet those needs (such as FCT_Quality Control Team Member, FCT_QC Training, etc.).
Organizational Security Roles will be displayed on a single-item selection field called “Concerned Company Structure” at Step 1 of the Document Control Process. The purpose of that field is to route the document change request to the appropriate Document Coordinator for processing, if you have different Document Coordinators for different parts of the organization or for different Document Types. If that is a need for your company, consider creating multiple Organizational Security Roles and assigning them accordingly.
Links to related information:
5. Users
The Username field is used for logging into SOLABS QM so must be unique for each user. Usernames must be in email format so will usually be the same as the user’s email address, but in lower-case characters. If you have users without active email accounts, you must still set their username in an email format. The email address field can be left blank for those accounts.
There is a mandatory Alias field for each user. When creating users manually it will be auto-populated with the initials of the user’s first and last name, so consider using that when completing information for your initial users. This field will need to be edited if there is already a user with the same initials. In that case, a middle initial could be added or a number could be added as a suffix. Alias fields are mandatory and need to be unique because they can be used as part of some complex Search queries if desired.
The Email Address field is optional but is necessary if the user will need to get any SOLABS QM Notifications for training assignments, document review/approval tasks, process tasks, etc. Consider leaving this field blank for your Validation environment if you do not want users to be getting emails as you complete any additional configuration or use it for training purposes. The UR-SOL-001 can be updated to add the email address field for the Production Environment if you would like SOLABS to pre-populate it for you.
The Account Type field is a single item selection field that has three choices.
- Standard must be chosen for users who will take any actions in SOLABS QM (create or modify a document, review or approve a document, act on a process task, administer training activities, etc.).
- External can be used to grant limited permissions (such as to review/approve a document or process step) to outside contractors, auditors, consultants, etc.
- Train ID is used for those users who will only view content for the purposes of completing assigned training activities. It can also be used for external users who should be limited to only viewing documents.
The Login Type field is a single item selection field that has two choices.
- Database is used for Trial, Sandbox or Validation instances of SOLABS QM. It is also used initially for all users in the Production instance. Select this as the Login Type for all users when completing the UR-SOL-001 template.
- User accounts will be updated to a Login Type of SOLABS Identity, or a Login Type specific to a Single Sign-On (SSO) feature such as Azure AD Premium, as they are scheduled to go live in the Production instance of SOLABS QM10. This triggers an automated email to the users to set up their initial password and access SOLABS QM. SOLABS will make this update for your implementation team when you are ready to Go Live with SOLABS QM. Your System Administrator(s) can then do the same for End Users in coordination with your Go Live/Training plan for the end user community.
The Manager field is mandatory for each user in order to support various email Notifications, Queries/Reports, and Second Confirmations for training assignments. It must be populated with the Username of the manager. If for some reason there is no manager, that field can be the same as the user’s Username field.
Links to related information:
https://docs.solabs.com/hc/en-us/articles/360046338233-SOLABS-QM-10-Use-of-the-External-Account-Type
https://docs.solabs.com/hc/en-us/articles/360041414334-Train-ID-vs-External-Account-Types
6. Custom Lists
Custom Lists are created to establish the values for any Single item selection and Multiple items selection System Attribute (Metadata) fields used in the Document Section, Training Section and Process Section.
Some Custom Lists are pre-defined and deployed with the software. The values for some of these pre-defined lists can be edited to adjust for client terminology.
Additional Custom Lists can be created to establish values for System Attribute fields required for your Document Types. You may want to take a look at the various documents used within the organization, and identify any that require the Author to always enter attribute information available from a list – such as Product Name, Batch Size, Manufacturing Area, etc. If Custom Lists are created to include that information, they can then become the Values for System Attribute fields that will be used to enter information into documents. System Attributes and their related values can enhance search capability.
Links to related information:
7. System Attributes
System Attributes are created to define the Metadata fields that will be required for Documents, Training Curricula, Training Activities and Process Steps. They can be created as Text, Numeric, Date, Single item selection or Multiple items selection fields. They can be set as Mandatory so that an author is required to enter the related information. Single item selection and Multiple items selection fields can also be set to have a Default Value from the associated Custom List.
- Single item selection (drop-down list) and Multiple items selection System Attribute fields will be associated with Values that can be defined as those from a Custom List, from current the SOLABS QM10 User List or from the current SOLABS QM10 Role Lists.
- Text fields and text areas would be for entry of free text information. They can also be configured to be populated by Quick Text (standardized terms/phrases created as a Custom List).
- Numeric fields would be used for such things as Batch Number, Sample Size, etc.
- Date fields would be used for such things as Start Date, End Date, Audit Date, etc. They can be set to allow dates in the past or not.
Some System Attributes are pre-defined and deployed with the software. Additional System Attributes can be created by the client. Considerations for System Attributes are similar to the considerations discussed above for Custom Lists. Additional System Attributes can be created to support metadata fields required for your Document Types. You may want to take a look at the various documents used within the organization, and identify any that require the Author to always enter specific attribute information – such as Date, Batch Number, Product Name, Batch Size, Manufacturing Area, etc. If System Attributes are created to define that information, they then become the metadata fields that will be used to enter the information into documents and enhance searching.
Links to related information:
8. Document Folders – Document Treeview
The folder structure in SOLABS QM that houses your documents is called the Document Treeview. Folders are created to organize how documents will be stored in the Document Treeview. Document permissions can be granted by folder. When creating a folder structure for the Treeview, keep in mind that those folders are used to assign privileges for the documents within the folder. Therefore, the folders should be created to easily accomplish appropriate levels of permissions to the sets of people who need them.
There are various ways to search for documents within SOLABS QM – left-hand Dashboards, Search fields, Saved Search Queries – so you don’t necessarily need the Treeview structure to be as intuitive to general Users as a paper file cabinet might be.
Sub-folders can be created as needed but consider limiting the number of sub-folder levels, since it can complicate the process of assigning privileges or even searching through them all to assign folder locations when creating Document Types or new documents.
There are four levels of privileges that can be assigned in SOLABS QM:
- Read Only – provides access only to view documents; this is the level set for the SOLABS General User role that is assigned by default to all Users. This is considered a “start-up” role and it is suggested that it be replaced by the Security or Function roles associated with the users at your organization that will require just Read Only permissions. This will allow the SOLABS General User role to be used if you ever have reason to provide Read Only permission to external parties.
- Review/Approve – provides access to view documents and also to complete assigned review or approval tasks related to those documents; assigned Reviewers or Approvers of documents need to have at least View privileges to the folder in which those documents reside.
- Modify – provides access to create documents, to modify documents and to assign review/approval cycles for documents. Document authors need to have at least Modify privileges to the folder in which those documents reside.
- Administer – provides full access to all of the above activities, as well as setting/modifying the privileges on folders and documents.
Links to related information:
https://docs.solabs.com/hc/en-us/articles/360043524413-SOLABS-QM-10-DOCUMENT-Section-Privileges
9. Document Types
Establishing Document Types allows differentiation between your documents with respect to default settings for Document Details, Standard Attributes, System Attributes and Document Ownership. This allows storage of all different types of documents within the same Document Treeview and defines the metadata that authors will be required to enter for a given Document Type.
Some Document Types are provided by default with the Core Software to support functionalities related to the PROCESS, TRAINING and TASK sections. They are prefixed by “Support Document for” and cannot be modified. Another Document type that is provided by default with the Core Software is the Basic Document. This Document Type is available to be used for documents that don’t require any more unique settings. As mentioned above, in order to differentiate between documents, additional Document Types can be created.
Creating a Document Type and defining attributes for that Document Type ensures that each document of that type is created using a standard format and contains consistent meta-data fields to capture all the required information. This can be very helpful for queries and reports.
When considering how many Document Types to create, there are different approaches that can be followed:
- If a Document Type is created for each folder in the Treeview, the author will have the convenience of not needing to select the location for a new document, since it will default to the location selected for that Document Type. However, if you have a large number of folders in your Treeview, this can require creation of large number of Document Types, some of which may include the same settings.
- If some of the documents in the Treeview folders have the same requirements for how they are numbered, whether or not training is typically required, their periodic review requirements or their metadata field requirements, you may be able to create one Document Type that will apply to multiple subfolders – and can therefore be created for the higher folder level. Examples might be Standard Operating Procedures – if there are subfolders for departmental SOPs, it may not mean that their format and requirements are different.
Think about all the different types of documents used in your organization and consider the following questions regarding them:
- Are people usually required to train on that document type?
- Does creation or revision of that document type usually require owner/manager approval?
- Does that document type require controlled numbering?
- Does that document type require an Effective Date?
- Does that document type require a Periodic Review cycle?
- Is there specific information that must always appear on that document type?
- Examples: lot number, department name, batch size, product name, etc.
Depending on the answers to these questions, you may be able to group documents into the same Document Type.
Another consideration in Document Type settings is whether or not you plan to use the Document Control Process to manage changes for the related documents. There are two Document Type settings that are critical to the process workflow for the Document Control Process: whether Owner-Manager Approval is required and whether Training is required. These Yes or No settings control whether or not Steps 2 and 4 of the Document Control Process workflow will be necessary.
When a Document Type is chosen by a document author, all of the default settings established for that Document Type will come into the authoring screen. Most can then be edited as needed for individual documents.
Links to related information:
10. Document Workflow Templates
Document Workflow Templates are default lists of Reviewers and Approvers that can be defined for document Review Cycles and Approval Cycles. These Document Workflow Templates can be created for each Document Type, shared across multiple Document Types, or created for scenario-based review cycles (such as for standard departmental approval workflows, author-only approvals, etc.).
For the Document Types you have created, think about whether there may be people or Functional Roles who typically are required to review or approve those documents. If so, you could create a default Workflow Template for that Document Type, or for multiple Document Types that require the same reviewers and approvers.
Think about whether you have other review or approval scenarios that may apply across many document types, such as Departmental review/approval, the need for an Author-only approval for import of scanned documents, etc.
The active Document Workflow Templates can then be selected by a document author, pulling in those names for the Review Cycle and/or Approval Cycle for their new/revised document. These are default lists that are easily edited at the document level to either remove a person or add an additional person.
Links to related information:
11. PDF Rendering Templates
PDF Rendering Templates allow setup of document Cover Page requirements, Headers and status Watermarks that will be applied when documents are rendered to PDF format. If there is no PDF Rendering Template defined for a Document Type, then the system will use the default template set in the application.
For the Document Types you have created, think about whether there are any common requirements with respect to whether company address information is required, whether standard headers are required and whether status watermarks will be required. If so, you could create a default Workflow Template for that Document Type, or for multiple Document Types that require the same reviewers and approvers.
Also, think about what document attribute information you would like to be available on printed documents – such as Title, Control Number, Effective Date, etc.
Links to related information:
Comments
0 comments
Please sign in to leave a comment.