blog-build-agile-object-security-model-png

Building an Agile Object and Security Model – Step by Step

by Rafik Mankarious |

Nov 17, 2020 |

How to define an agile Object Model

Document’s metadata

Let’s start our discussion on how any company may receive a new document. It could be either in electronic form or in a physical form that requires scanning and transformation to an electronic version. So before storing this document inside any document management system, let’s think together on how to enhance this document with some metadata that helps retrieving it easily in the future.

Most people may think on creating a separate document type with a set of metadata for each type they have (for example: Document type named invoices with defined attributes like invoice date, invoice number, invoice amount, client name, … etc.) but this approach increases the administration tasks for all of those defined doctypes. So, let’s start thinking about defining an agile object model that fits a wide range of different document types).

Q: What metadata could be common across any type of document?
A: Document Date & Document Number

Exactly, for example:

If we have a document of type “Invoice” then we have Invoice Date and Invoice Number.
If we have a document of type “Contract” then we have Contract Date and Contract Number.
If we have a document of type “Certificate of Calibration” then we have Certificate Date and Certificate Number.

Q: How can I classify my document type?
A: Great question, Let’s start with this concept. Add 3 metadata that define the document as follows:

Business Unit (Department/Site)
Document Type
Sub-Document Type

Example 1: Assume we have a department called “Finance” that manages different document types so here is a scenario on how to manage those documents by classifying them into Document Type and Sub-Document Types:

Business Unit (Department/Site): Finance
Document Type: Purchasing
Sub-Document Type: Requisition, Purchase Order & Procurement Card

Business Unit (Department/Site): Finance
Document Type: Accounts Payable
Sub-Document Type: Payment Request, Credit Memo & Disbursement Voucher

Example 2: Assume we have a department called “Manufacturing” that manages different document types so here is another scenario on how to manage those documents by classifying them into Document Type and Sub-Document Types:

Business Unit (Department/Site): Manufacturing
Document Type: Certificates
Sub-Document Type: Certificate of Calibration, Certificate of Analysis & Certificate of Inspection

Business Unit (Department/Site): Manufacturing
Document Type: Supplier Records
Sub-Document Type: Contracts, Master Service Agreement, Quality Assurance Agreement, Performance Records & Miscellaneous

Q: What other metadata could be used to enrich the search feature?
A: There are many other metadata that could be used but let’s focus on generic ones that can be used to capture any other information listed on the document that we intend to archive

Description/Comments/Keywords
Reference Number (can be used to capture Account number, Part number, Lot number, Manufacturer number, Serial number, … etc.)
Reference Name 1 (can be used to capture Vendor name, Client name, Patient name, First name, … etc.)
Reference Name 2 (can be used to capture Last Name or any other names located on the document)
ID (can be used to capture Employee ID, User ID, … etc.)
Product/Project (can be used to capture Product Name, Product number, Project Name, Project number, … etc.)
Box Number (can be used to reference the Box number where the original physical document is located)
Document Source (can be used to capture the source of the document like Scanning, received by email, fax, Manual Import, added by Job, … etc.)

Q: What other metadata could be added if I am scanning physical documents?
A: Here is a list of metadata that can be used to capture auditing information during scanning process:

Scan Operator
Scan Date
Index Operator
Index Date
Scanned Pages
Batch Name/ID

Great! Now, we came with a list of generic metadata that can be used to easily classify & enrich any document.

Build-Agile-Object-Security-Model-1-300x250

Folder Structure

Simply, we can use the “Type” attributes on defining an easily readable folder structure as follows:

Level 1 (L1): BU (Department/Site)
Level 2 (L2): Document Type
Level 3 (L3): Sub-Document Type
Level 4 (L4): can be either structured to be YYYY_MM (Document Date), or Document number (if unique).That’s why all of the above attributes should be mandatory in order to be used on defining the folder structure.

Build-Agile-Object-Security-Model-2-300x79

How to define an agile Security Model

Permission Set

Another interesting topic which is how to define an agile security model that can easily grants access to documents within an organization based on users’ role.

Let’s build our security model assuming that a user within a business unit (Department/Site) can either access all defined Document types within that BU, or can access specific document type(s).

Here is the suggested permission set on each Level of the defined Folder structure.

Build-Agile-Object-Security-Model-3-300x251

Note: <BU> & <DocType> are placeholders where:

<PREFIX> can be replaced with system name or any other prefix to help syncing AD groups based that starts with this prefix.
<BU> represents Business Unit (Department or Site).
<DocType> represents defined document type.

Let’s take an example of having a “Finance” BU with 2 document types (Purchasing & Accounts Payable) with some sub-document types, and translate the above concept into some AD groups:

Type Matrix:

Build-Agile-Object-Security-Model-4-300x91