Documents in FormKiQ can be classified and organized using the following features:
Document Metadata Management
FormKiQ's metadata model is the foundation of its document classification, search, workflow routing, and governance capability. Every document in FormKiQ carries a rich, flexible metadata record that can be defined, extended, and updated to reflect the classification requirements of your organization — without schema constraints, without database migrations, and without platform reconfiguration.
Available with:
How FormKiQ's metadata model works
FormKiQ stores document metadata in Amazon DynamoDB, alongside a set of system-managed attributes populated automatically at the point of document creation — content type, original filename, upload timestamp, document size, version history, and others. Beyond these system attributes, every document can carry an unlimited number of custom metadata attributes defined by your organization, structured to reflect your document classification model, your workflow requirements, and your search and retrieval needs.
Metadata attributes in FormKiQ are flexible by design. You are not constrained to a predefined schema — attributes can be added, updated, and removed on individual documents or applied across collections without affecting the underlying storage architecture. This means your metadata model can evolve alongside your operational requirements without requiring platform reconfiguration or data migration.
Document Classification Schemas
For organizations that need to enforce metadata structure and consistency across document collections, FormKiQ's Document Classification Schemas provide a governed layer on top of the flexible metadata model. Classification schemas define the attributes that documents of a given type must carry, validation rules that ensure attribute values meet defined constraints, and search patterns that make classified documents discoverable through consistent query structures.
Schemas can be applied at the point of document intake — through the API, the Console, or an automated workflow — ensuring that classification is applied consistently from the moment a document enters FormKiQ rather than retroactively.
Managing metadata through the Document API
The FormKiQ Document API provides complete RESTful methods for metadata management across the full document lifecycle:
- Adding metadata — apply custom attributes to a document at the point of upload or at any subsequent point in the document lifecycle, individually or in bulk
- Updating metadata — modify existing attribute values as document status, classification, or workflow state changes — for example, updating review status as a document moves through an approval workflow, or updating retention category as a record is reclassified
- Removing metadata — delete individual attributes from a document record where they are no longer applicable, without affecting the document itself or other metadata attributes
- Bulk metadata operations — apply, update, or remove metadata attributes across document collections through API batch operations, supporting large-scale reclassification and metadata remediation programs
- Metadata retrieval and query — retrieve metadata records for individual documents or query across the document collection by attribute value, supporting application integrations that need to surface documents based on their classification attributes
Managing metadata through the Document Console
The FormKiQ Document Console provides an interface for metadata management that does not require API access or developer involvement — appropriate for content managers, records administrators, and other operational users who need to classify, reclassify, or update document metadata as part of their day-to-day workflow.
Through the Console, authorized users can:
- View the complete metadata record for any document they are authorized to access
- Add, edit, and remove custom attributes on individual documents
- Apply classification schemas to documents and review schema validation results
- Search and filter the document collection by metadata attribute values
- Review system-managed attributes including version history, access log, and workflow state
Metadata and DynamoDB — direct access for advanced use cases
Because FormKiQ stores document metadata in Amazon DynamoDB within your own AWS account, your technical team has direct access to the metadata store through the AWS CLI and SDK — in addition to the FormKiQ API. This means:
- Custom reporting and analytics applications can query the DynamoDB metadata store directly for use cases where direct database access is more efficient
- AWS native analytics services — Amazon Athena, AWS Glue, Amazon QuickSight — can be connected directly to the metadata store to build reporting and visualization layers on top of the document collection
- Custom automation and integration pipelines can read and write metadata through DynamoDB directly for high-throughput scenarios where API-based metadata management introduces unnecessary latency
- DynamoDB Streams can trigger downstream processes in response to metadata changes — initiating a workflow when a classification attribute is updated, or sending a notification when a retention date is reached
Direct access to the metadata store is a meaningful differentiator from SaaS document management platforms where metadata is stored in vendor-managed infrastructure inaccessible to the customer's own systems.
Metadata across the FormKiQ platform
Document metadata flows through every capability in the FormKiQ platform:
- Search — metadata attributes are indexed and queryable through FormKiQ's search layer, making the document collection discoverable by any attribute combination
- Workflow routing — workflow rules evaluate metadata attribute values to determine routing, escalation, and processing decisions
- Access control — attribute-based access control (ABAC) policies use metadata attribute values to enforce access decisions — a document's jurisdiction attribute can determine which regional team can access it, or a classification level can determine which roles can view it
- Retention and lifecycle — retention schedules and disposition rules evaluate metadata attributes to determine when a document enters a hold, becomes eligible for disposition, and what disposition action applies
- KnowledgeBase — document metadata attributes are available to the KnowledgeBase module's retrieval model, allowing natural language queries to be scoped and filtered by classification attributes alongside full-text content
AI-Powered Document Classification and Extraction
FormKiQ's AI Processing and Analysis module brings large language model capabilities to document classification, sensitivity detection, and metadata extraction — running entirely within your AWS account through Amazon Bedrock. These capabilities apply to the classification layer of document management, automatically determining what a document is, what sensitive content it contains, and what structured attributes can be extracted from it at the point of ingestion.
Available as an Add-On Module with:
Document Type Classification
Automatically identify and classify the type of each document as it enters FormKiQ — determining whether an incoming document is a contract, invoice, application, correspondence, or any other category relevant to your document program — and applying the appropriate classification schema, metadata attributes, and workflow routing based on that determination. Classification models are configured to your document taxonomy, with confidence scoring that routes low-confidence results to a human review queue.
Common fits: high-volume mixed document intake, mailroom digitization, insurance and financial intake, grants and applications processing.
Content Sensitivity Classification
Automatically detect the presence of PII, PHI, financial data, legally privileged content, and other sensitive content categories in incoming documents — applying appropriate access controls, handling requirements, and metadata attributes at the point of ingestion. Sensitivity classifications can trigger downstream actions such as access restriction escalation, restricted queue routing, or privacy officer notification. Models are configured to the specific data categories relevant to your regulatory obligations.
Common fits: regulated document intake programs with data protection obligations, healthcare document processing, legal privilege detection, HR and financial services document intake.
Metadata Extraction
Automatically extract structured metadata from document content — identifying and populating key attributes such as dates, names, organization identifiers, reference numbers, and amounts — and applying those extracted values as FormKiQ metadata attributes without manual data entry. Extraction models are configured to the specific fields relevant to each document type, with confidence scoring to flag low-confidence extractions for human review.
Common fits: contract and legal document processing, accounts payable and invoice processing, grants and applications intake, insurance claims, HR document processing, records digitization programs.
Multi-Team and Multi-Tenant Document Management
FormKiQ's multi-team and multi-tenant architecture is built into the platform's foundation — not added as a configuration layer on top of a single-tenant design. Whether you are managing documents across internal departments, business units, and regional teams, or operating a multi-tenant SaaS product where each customer requires complete isolation from other tenants, FormKiQ's Site ID model provides the separation, access control, and governance structure to support both use cases within a single deployment.
Available with:
How multi-tenancy works in FormKiQ
FormKiQ's multi-tenant model is built around the concept of Site IDs — discrete, isolated document environments within a single FormKiQ deployment. Each Site ID represents a separate document space with its own document collection, metadata store, access policies, classification schemas, workflows, and audit trails. Documents in one site are completely isolated from documents in another — users, applications, and integrations assigned to one site cannot access documents in another site without explicit cross-site authorization.
Site IDs can represent anything your organizational model requires — a department, a business unit, a regional office, a customer account in a multi-tenant SaaS product, a project, or any other logical grouping where document isolation is operationally or contractually required.
Identity and access management with Amazon Cognito
FormKiQ uses Amazon Cognito for identity management across multi-team and multi-tenant deployments. Cognito manages user pools, group assignments, and authentication for both internal users — staff, administrators, reviewers — and external users — customers, partners, applicants, or other counterparties who need access to documents within a specific site.
User group assignments in Cognito determine which Site IDs a user can access and what level of access they have within each site. A user can be assigned to one site or multiple sites, with different access levels in each — for example, a user might have read-only access to a shared reference document site and full administrative access to their own departmental site. A system administrator can have cross-site visibility for governance and audit purposes while standard users remain scoped to their assigned sites.
For multi-tenant SaaS deployments, each customer tenant is assigned to a dedicated Site ID — ensuring that tenant users can only ever access their own tenant's documents, regardless of how the application layer surfaces the FormKiQ document store.
Site ID architecture for common use cases
Internal multi-team deployment
A large organization with multiple departments, regions, or business units deploys FormKiQ with a Site ID per organizational unit. Each team manages its own document collection under its own access policies and classification schemas, while a central governance function retains cross-site visibility for audit, compliance, and records management purposes. Shared document collections — corporate policies, reference materials, regulatory documents — can be made accessible across sites without breaking the isolation of each team's operational documents.
Multi-tenant SaaS product
A SaaS vendor building document management capability into their product uses FormKiQ's Site ID model to provide complete per-customer document isolation within a single FormKiQ deployment. Each customer is assigned a dedicated site, with its own document collection, metadata model, and access policies. The SaaS vendor's administrative layer can access all sites for operational management, while customer users are strictly scoped to their own site. New customer tenants can be provisioned by creating a new Site ID — no infrastructure changes required.
Partner and client document programs
A professional services or legal organization uses Site IDs to isolate client matter documents — each client or matter is assigned a dedicated site, ensuring that documents for one client are never accessible to another, and that the access policies governing each matter reflect the confidentiality requirements of that specific client relationship.
Multi-jurisdiction deployment
An organization with data residency requirements in multiple jurisdictions deploys separate FormKiQ instances per region, each with its own Site ID structure for internal teams and external parties within that jurisdiction. Cross-region authentication allows users to operate across jurisdictions where authorized, while data remains isolated within each regional instance.
Document Classification Schemas
FormKiQ's Document Classification Schemas provide a governed structure for document metadata — allowing organizations to define the attributes that documents of a given type must carry, enforce validation rules that ensure metadata quality and consistency, and build efficient search patterns that make large document collections discoverable at scale.
Classification schemas sit between FormKiQ's flexible metadata model — which allows any attribute to be added to any document — and the governed, consistent classification that regulated document programs, compliance audits, and operational workflows depend on. Without schemas, metadata quality depends on the discipline of the people adding it. With schemas, metadata quality is enforced by the platform.
Available with:
What classification schemas define
Required attributes
Attributes that must be present on every document assigned to a given schema. A document cannot be fully ingested or classified under a schema until all required attributes have been provided. For example, a grants application schema might require applicant identifier, funding category, submission date, and program year. A contract schema might require counterparty name, contract type, effective date, and jurisdiction. Required attributes ensure that the minimum information needed to govern, route, and retrieve a document is always present.
Optional attributes
Attributes that are defined within the schema and available for population but not required for schema compliance. Optional attributes provide a structured vocabulary for additional classification without making every attribute mandatory — for example, a contract schema might define an optional attribute for renewal date that is relevant for some contract types but not others.
Default attribute values
Attributes that are pre-populated with a defined default value at the point of schema assignment, reducing the manual effort required to classify documents and ensuring consistency across large ingestion volumes. Default values can be overridden where the specific document requires a different value, but they ensure that documents are never left unclassified in attributes where a sensible default applies.
Validation rules
Rules that enforce the format, range, or permitted values of attribute inputs — ensuring that metadata is not only present but correctly structured. A date attribute can be validated to ensure it is in the correct format. A jurisdiction attribute can be validated against a defined list of permitted values. A document identifier attribute can be validated against a pattern that ensures it matches your organization's document numbering scheme. Validation rules are enforced at the point of metadata entry — through the API, the Console, or an automated workflow — preventing incorrectly structured metadata from entering the document record.
Composite keys and search efficiency
Classification schemas in FormKiQ include Composite Key functionality — a capability that significantly improves search performance and cost-efficiency for large document collections stored in Amazon DynamoDB. DynamoDB's native query model is optimized for primary key lookups; querying across multiple metadata attributes simultaneously without composite keys requires either a full table scan, which is slow and costly at scale, or a secondary index for every attribute combination, which adds complexity and cost.
FormKiQ's Composite Keys solve this by combining multiple metadata attributes into a single indexed key at the point of document classification — allowing complex multi-attribute queries to execute as efficient DynamoDB key lookups rather than scans. The composite key structure is defined within the classification schema, so the search patterns your organization needs are built into the document's classification model from the start rather than retrofitted after the collection has grown.
Schema enforcement through AWS Lambda
Classification schema validation in FormKiQ is implemented through AWS Lambda functions running within your own AWS account. This means:
- Validation logic executes within your infrastructure boundary — metadata is validated in your account, not on an external validation service
- Validation functions can be extended or customized where your organization's validation requirements go beyond the standard schema capabilities
- Validation performance scales with your document ingestion volume through Lambda's serverless execution model
- Validation failures are logged within your AWS environment, supporting audit and troubleshooting requirements
Classification schemas across the FormKiQ platform
- Workflow routing — workflow rules can evaluate schema compliance and attribute values to route documents to the appropriate queue or reviewer, ensuring that only fully classified documents proceed through the workflow
- Access control — ABAC policies can use schema-defined attributes to enforce access decisions, with schema compliance as a prerequisite for document accessibility in some configurations
- Search — composite key structures defined in schemas power efficient search across the document collection, with search patterns optimized for the attribute combinations your organization queries most frequently
- KnowledgeBase — schema-defined attributes are available to the KnowledgeBase retrieval model, allowing natural language queries to be scoped and filtered by classification attributes
- Retention and lifecycle — retention schedules and disposition rules evaluate schema-defined attributes to determine when documents are eligible for hold, review, or disposition