Using Amazon Web Services (AWS), FormKiQ provides secure and scaleable document storage, along with various features for adding and updating documents:
Scalable Document Storage
FormKiQ provides flexible, scalable document storage built on Amazon S3 and Amazon DynamoDB — two of AWS's most proven managed services — deployed entirely within your own AWS account. Every document, every version, and every metadata attribute lives in your infrastructure, under your access controls and encryption policies, with no shared storage layer between you and other FormKiQ customers.
Available with:
How document storage works
FormKiQ stores the original document binary in Amazon S3 and the document's metadata in Amazon DynamoDB. This separation of content and metadata is a deliberate architectural choice — it allows each layer to be optimized independently, queried through different access patterns, and governed under policies appropriate to each data type.
Amazon S3 — document content storage
Every document uploaded to FormKiQ is stored in S3 in its original format. S3 Versioning is enabled by default, providing a complete version history for every document — protecting against accidental overwrites, supporting audit requirements that demand access to prior versions, and enabling recovery from unintended changes without data loss. S3's durability and availability characteristics make it the appropriate foundation for document collections that need to be reliably accessible over years and decades.
Amazon DynamoDB — document metadata storage
Every document in FormKiQ is accompanied by a rich metadata record stored in DynamoDB — including content type, original filename, upload timestamp, classification attributes, and an unlimited number of custom metadata attributes defined by your organization. This metadata model is what enables FormKiQ's document search, classification, workflow routing, and access control to function at scale across large collections without performance degradation.
The combination of S3 and DynamoDB enables any number of integrations and access patterns — both through the FormKiQ API and through direct connectivity with either AWS service where your architecture requires it.
Storage architecture benefits
- Documents are stored in your own S3 buckets — no shared storage, no vendor data access
- S3 Versioning provides complete document history and protection against accidental change or deletion
- Unlimited custom metadata attributes per document with no schema constraints
- DynamoDB's performance characteristics support fast metadata retrieval across collections of any size
- Direct S3 and DynamoDB connectivity available for integrations that need to bypass the API layer
- Storage lifecycle policies configurable through Amazon S3 storage tiers for cost-effective management of large or long-lived collections
- Encryption at rest applied to both S3 and DynamoDB storage layers using AWS KMS
Bulk Document Upload and Transfer
FormKiQ provides multiple methods for importing documents at scale — from initial bulk migration of existing collections through to ongoing automated transfer and synchronization. The right approach depends on the volume, source, and operational context of the transfer requirement.
FormKiQ CLI
Available with:
The FormKiQ CLI is a command-line tool provided with Essentials, Advanced, and Enterprise editions that enables high-speed bulk document upload and management directly from the command line. The CLI is the primary tool for bulk document operations — initial migrations, large-scale imports, batch processing, and scripted document management workflows that benefit from direct command-line control rather than API integration or UI-based upload.
The CLI uses FormKiQ's asynchronous document processing architecture to handle large volumes efficiently — documents are ingested, processed, classified, and stored without blocking operations or requiring manual intervention for individual files. Metadata can be specified at the point of upload, applied from a manifest, or populated through FormKiQ's classification and tagging pipeline after ingestion.
Common uses for the FormKiQ CLI:
- Initial bulk migration from file servers, network shares, or existing document stores
- Large-scale import of digitized documents from capture workflows
- Scripted batch operations for ongoing document management programs
- Integration with automation pipelines where command-line control is preferred over API calls
- Administrative document management tasks that benefit from direct CLI access
Secure File Transfer Gateway
Available with:
For ongoing, automated document transfer and synchronization requirements that go beyond initial bulk upload, FormKiQ's Secure File Transfer Gateway provides a structured connection layer for continuous or scheduled document movement between external sources and FormKiQ.
Where the CLI is designed for bulk operations initiated and controlled by your team, the Secure File Transfer Gateway is designed for extended use cases where document transfer needs to happen automatically, on a schedule, or in response to external events — including:
- Synchronizing documents between a file server or network share and FormKiQ on an ongoing basis
- Receiving documents deposited by external parties via SFTP into FormKiQ's governed document layer
- Sending documents from FormKiQ to external SFTP destinations as part of a defined workflow
- Ingesting files deposited into cloud storage locations on a scheduled or event-driven basis
- Managing ongoing document exchange with partners, regulators, or counterparties through secure transfer protocols
The Secure File Transfer Gateway applies FormKiQ's classification, metadata, and routing model to documents as they arrive — so incoming documents are processed and governed from the point of transfer, not after manual review.
Choosing the right transfer approach
| FormKiQ CLI | Secure File Transfer Gateway | |
|---|---|---|
| Primary use case | Bulk upload and administrative operations | Ongoing automated transfer and synchronization |
| Initiated by | Your team, on demand or scripted | Scheduled, event-driven, or external party deposit |
| SFTP support | — | Yes |
| Network share synchronization | — | Yes |
| Cloud storage ingestion | — | Yes |
| Metadata application at upload | Yes | Yes |
| Classification pipeline integration | Yes | Yes |
| Available with | Essentials, Advanced, Enterprise | Advanced, Enterprise |
For organizations with both initial migration requirements and ongoing transfer needs, the CLI and Secure File Transfer Gateway are intended to be used together — the CLI for the initial bulk import and the Gateway for the ongoing synchronization and external document exchange that follows.
Enhanced Forms and Form Builder — Currently in Preview
FormKiQ's Enhanced Forms and Form Builder is currently available in preview to Advanced and Enterprise customers. The feature is designed to provide structured, FormKiQ-native online forms that connect directly to document intake workflows — reducing the gap between form submission and governed document processing that exists when forms and document management are handled by separate systems.
Currently in Preview with:
Organizations interested in participating in the preview are encouraged to contact FormKiQ to discuss access and provide feedback that shapes the production release.
What Enhanced Forms and Form Builder provides
FormKiQ's forms capability is designed around the document intake use case — forms are not standalone data collection tools but a structured entry point into FormKiQ's document and workflow layer. When a form is submitted, the result enters FormKiQ as a governed document record, with metadata, classification, and workflow routing applied at the point of submission rather than through a downstream manual process.
Form design and management
Forms are designed by content managers using a visual form builder — without requiring developer involvement for standard form creation and updates. Forms can be built from scratch to match a defined intake process, or created from existing paper forms to provide a digital equivalent that preserves the structure and field model of the original. Field validation, conditional logic, and required field enforcement can be configured within the builder to ensure submissions arrive complete and correctly structured.
Internal and external access
Forms can be made available to internal users — staff, reviewers, administrators — or to external parties, including members of the public, applicants, vendors, or other counterparties, based on configurable access requirements. Access controls determine who can see and submit each form, with FormKiQ's existing authentication and authorization model applied to form access in the same way it is applied to document access.
Paper form equivalence
For organizations with existing paper-based intake processes, the Form Builder supports creating digital forms that mirror existing paper forms — preserving field structure, layout, and submission requirements while enabling electronic submission, digital storage, and direct integration with FormKiQ's document and workflow layer. This is particularly relevant for grants, applications, and regulatory intake programs where paper forms are a formal part of the process and the digital equivalent needs to match the established format.
Workflow integration
Form submissions flow directly into FormKiQ's workflow, classification, and routing architecture. A submitted form can trigger document intake workflows, route to review queues, apply metadata and classification based on form content, and initiate downstream processes — all without manual intervention between submission and processing. For grants management programs, this means applications submitted through the form enter the review and scoring workflow immediately on submission, with all form data captured as document metadata available for search, filtering, and reporting.
Current preview focus
The current preview is particularly focused on grants management and application intake use cases — environments where form-based document intake is a core operational requirement, where both internal and external users need access to forms, and where the connection between form submission and governed document processing is a critical workflow dependency.
Feedback from preview customers in these use cases is directly informing the production feature design, including the form builder interface, access control model, paper form equivalence capability, and workflow integration depth.
Planned production availability
Enhanced Forms and Form Builder is planned for production availability with FormKiQ Advanced and FormKiQ Enterprise. Specific release timing will be communicated to preview participants and announced through FormKiQ's standard release channels.
Inbound Webhooks
FormKiQ's inbound webhook capability allows external services, applications, and automated processes to create and submit documents directly into FormKiQ without requiring direct API integration — providing a lightweight, standards-based entry point for document intake from any system that supports webhook-based event delivery.
Available with:
How inbound webhooks work
An inbound webhook in FormKiQ is a unique URL endpoint that, when called by an external service, creates a document record in FormKiQ and triggers the associated intake workflow. Webhooks can be configured to receive documents, form submissions, event payloads, and other content from external sources, with FormKiQ processing the incoming data and routing it according to the configured workflow and classification rules.
Webhooks are created and managed through the FormKiQ Document API, and each webhook can be configured with its own metadata mapping, classification rules, and workflow routing — so documents arriving through different webhooks are automatically handled according to the intake process appropriate for that source.
Open and authenticated webhooks
FormKiQ supports both open and authenticated inbound webhooks, giving you control over the security posture of each webhook endpoint based on the source and sensitivity of the incoming documents.
Open webhooks
Accept submissions from any source without requiring authentication credentials — appropriate for low-sensitivity intake scenarios where ease of submission from external parties is the priority, or where the external service does not support outbound authentication.
Authenticated webhooks
Require the submitting service to provide valid credentials as part of the webhook call — appropriate for intake scenarios involving sensitive documents, regulated content, or sources where you need to verify that submissions are coming from an authorized system. Authenticated webhooks use FormKiQ's standard authentication model, ensuring that webhook-based document intake is subject to the same access control framework as any other document operation.
Common uses for inbound webhooks
- Receiving documents from third-party SaaS platforms that support webhook-based event delivery
- Capturing form submissions from external form providers directly into FormKiQ's document layer
- Integrating with automation platforms such as Microsoft Power Automate, Zapier, or similar tools to route documents from connected services into FormKiQ
- Receiving event-triggered document submissions from custom applications without building a full API integration
- Capturing inbound notifications, reports, or generated documents from external systems as FormKiQ records
Webhook and workflow integration
Inbound webhooks can be connected to FormKiQ's workflow, classification, and routing architecture — so documents arriving through a webhook can be automatically classified, tagged, routed to a review queue, or trigger a downstream process without manual intervention. Combined with FormKiQ's Document Gateways, webhooks extend the range of sources from which documents can enter a governed FormKiQ workflow.
AWS Command Line Interface (CLI) Access
Because FormKiQ deploys entirely into your own AWS account, every resource created and used by FormKiQ is accessible through the AWS Command Line Interface — giving your technical team direct access to the underlying AWS infrastructure that powers your FormKiQ deployment, using the same tooling they use for every other AWS resource in your environment.
Available with:
What AWS CLI access means for FormKiQ deployments
Standard SaaS platforms abstract infrastructure from the customer entirely — you interact with the product through its interface and API, and the underlying systems are inaccessible. FormKiQ's customer-managed deployment model inverts this: because the infrastructure is yours, you have direct access to every component through the AWS CLI, with no FormKiQ-imposed restrictions on how you interact with your own environment.
This matters for several operational scenarios:
Infrastructure management and automation
Your operations and DevOps teams can interact with FormKiQ's underlying AWS resources — S3 buckets, DynamoDB tables, Lambda functions, CloudFormation stacks, and others — using the same AWS CLI workflows they use for the rest of your infrastructure. FormKiQ deployments can be included in existing infrastructure automation, monitoring, and management pipelines without requiring separate tooling or vendor-specific management interfaces.
Direct resource access for advanced operations
The AWS CLI provides direct access to the S3 buckets and DynamoDB tables that store FormKiQ documents and metadata — enabling advanced operations that complement the FormKiQ API, including direct S3 operations for large-scale document management, DynamoDB queries for custom reporting and analysis, and CloudWatch access for operational monitoring and alerting.
Security and compliance tooling integration
AWS CLI access means FormKiQ's infrastructure can be included in your existing AWS security tooling — AWS Security Hub, AWS Config, AWS CloudTrail, and GuardDuty — without any special configuration or vendor involvement. Security assessments, compliance checks, and audit log collection operate across your FormKiQ deployment in exactly the same way as they operate across the rest of your AWS environment.
Disaster recovery and backup operations
Direct AWS CLI access supports custom backup, recovery, and business continuity operations — S3 replication configuration, DynamoDB backup and restore, and cross-region recovery workflows can all be managed through the AWS CLI as part of your organization's broader DR program.
Document Deeplinks
FormKiQ's Deeplink capability allows documents stored in FormKiQ to be referenced, accessed, and interacted with from external systems — without duplicating the document or moving it out of the governed FormKiQ environment. A Deeplink is a persistent, structured reference to a FormKiQ document that can be embedded in any external system, enabling seamless access and interaction while keeping the document itself under FormKiQ's access control, metadata, and audit model.
Available with:
What Deeplinks enable
Cross-system document reference without duplication
The fundamental problem Deeplinks solve is the duplication that occurs when documents need to be accessible across multiple systems. Without a reference model, organizations typically copy documents into each system that needs them — creating multiple versions, breaking audit continuity, and making governance impossible. A Deeplink maintains a single governed copy of the document in FormKiQ while making it accessible from any system that supports link-based document reference.
Metadata enrichment from external systems
Deeplinks are not read-only references. External systems that reference a document through a Deeplink can contribute metadata back to that document's FormKiQ record — enriching the document's attributes with context from the referencing system. A case management system referencing a document through a Deeplink can contribute case number, case status, and assigned reviewer as metadata attributes on the FormKiQ document record, making that document discoverable through FormKiQ search by case-level attributes without requiring any direct integration between the case management system and FormKiQ's data layer.
Governed access through external interfaces
When a user accesses a document through a Deeplink from an external system, FormKiQ's access control model applies — the user sees the document only if they are authorized within FormKiQ's access policy for that document. This means that surfacing FormKiQ documents within external system interfaces does not bypass or circumvent FormKiQ's governance model. Access is controlled, audited, and consistent regardless of which interface the user accesses the document from.
Search and discovery across referenced documents
Documents referenced through Deeplinks — including documents in external systems that have been linked into FormKiQ — are included in FormKiQ's search and discovery capability. The metadata contributed by the referencing system is searchable alongside FormKiQ's native metadata, giving users a unified search experience across the full document collection regardless of where each document originated or which system referenced it.
Deeplinks and Document Gateways
Deeplinks can be combined with FormKiQ's Document Gateways and workflow architecture for extended capability. Where a Document Gateway brings a document from an external source into FormKiQ as a governed record, a Deeplink maintains a reference to a document that remains in an external system while making it accessible and enrichable within FormKiQ. The two capabilities serve different use cases and can be used together in environments where some documents need to be ingested and governed entirely within FormKiQ while others need to remain in their source system but be referenced and enriched through FormKiQ's metadata and search layer.
Common uses for Deeplinks
- Surfacing FormKiQ documents within ERP, CRM, case management, and HRIS interfaces without duplicating the document in each system
- Referencing external documents — stored in systems FormKiQ does not fully manage — within FormKiQ's metadata and search layer for unified discovery
- Providing external parties with governed, access-controlled links to specific documents without exposing the broader repository
- Connecting documents to the business records they relate to — contracts to vendor records, case documents to case records, policy documents to HR records — through persistent, auditable references
- Enriching FormKiQ document metadata from the context of the referencing system, building a richer searchable record than either system could maintain independently
Full Document Encryption
Using AWS Key Management Service (KMS) and the built-in encryption tooling provided by CloudFront, S3, DynamoDB, and other AWS services, FormKiQ provides full encryption in transit and at rest across every component of the platform. Because FormKiQ deploys into your own AWS account, encryption configuration is entirely under your control — not shared with other customers or managed by a third-party vendor.
Available with:
Encryption in transit
All data moving between clients, APIs, and storage layers is encrypted using TLS, enforced through Amazon CloudFront and API Gateway. No unencrypted data transmission is permitted within the platform architecture.
Encryption at rest
All documents and metadata stored in Amazon S3 and DynamoDB are encrypted at rest using AWS KMS-managed keys. Encryption is applied at the storage layer — documents are never written to disk unencrypted.
Complete encryption under your control
By using a custom KMS Key Store, FormKiQ gives you direct ownership of encryption keys — not a shared key managed on your behalf by a SaaS vendor. Key creation, rotation, access policy, and audit logging are all under your control, with every key usage event recorded in AWS CloudTrail for complete auditability.
This level of encryption control satisfies the requirements of major compliance frameworks and certification programs, including GDPR, HIPAA, SOC 2, ISO 27001, PIPEDA, and Quebec Law 25.
Hardware-level encryption with AWS CloudHSM
For organizations with the most stringent encryption requirements, FormKiQ supports integration with AWS CloudHSM — dedicated hardware security modules that provide FIPS 140-2 Level 3 validated encryption. CloudHSM goes beyond software-based key management by storing and processing encryption keys in tamper-resistant hardware that is physically isolated and dedicated to your account.
This is the appropriate choice for organizations where regulatory frameworks, internal security policy, or contractual obligations require hardware-based key storage rather than software-managed KMS keys — common in defense, financial services, government, and healthcare programs with the highest data protection requirements.
With CloudHSM, encryption keys never leave the hardware module in plaintext, key operations are performed within the HSM itself, and full audit logs of every cryptographic operation are available through AWS CloudTrail.
Choosing the right encryption model
| Standard KMS | Custom KMS Key Store | AWS CloudHSM | |
|---|---|---|---|
| Encryption in transit and at rest | Yes | Yes | Yes |
| Customer-managed keys | Yes | Yes | Yes |
| Key audit logging via CloudTrail | Yes | Yes | Yes |
| Keys stored in AWS-managed infrastructure | Yes | — | — |
| Keys stored in customer-controlled key store | — | Yes | Yes |
| FIPS 140-2 Level 3 validated hardware | — | — | Yes |
| Dedicated hardware security module | — | — | Yes |
| Best for | Standard regulated workloads | Enhanced control requirements | Highest assurance requirements |
All three models are supported within FormKiQ's customer-managed AWS deployment. The right model depends on your specific compliance obligations, internal security policy, and the sensitivity of the documents being managed.
Compliance frameworks supported
FormKiQ's encryption architecture is designed to satisfy the technical controls required by major compliance frameworks. The following frameworks have specific encryption requirements that FormKiQ's KMS and CloudHSM integration can support:
- GDPR — encryption as a technical measure for personal data protection
- HIPAA — encryption of protected health information in transit and at rest
- SOC 2 — encryption controls supporting the Security and Confidentiality Trust Service Criteria
- ISO 27001 — cryptographic controls aligned with Annex A.10
- PIPEDA and Quebec Law 25 — appropriate security safeguards for personal information
- NIST 800-53 — cryptographic protection controls for federal and government programs
- FedRAMP — encryption requirements for cloud services used by US federal agencies
- PCI DSS — encryption of cardholder data in transit and at rest
Note: FormKiQ provides the encryption architecture and controls. Whether a specific deployment satisfies a given compliance framework depends on the complete configuration and operational context of that deployment, which should be validated by your legal, compliance, and security teams.
The Secure File Transfer Gateway has moved. View the Secure File Transfer Gateway →
The Email Ingestion Gateway has moved. View the Email Ingestion Gateway →
Custom Integration Development
For source systems not covered by FormKiQ's standard Document Gateways or Integration Frameworks, custom integration development provides a path to connect any external system to FormKiQ's document layer — either as a standalone service built against the FormKiQ Document API, or as a custom component built within FormKiQ's module architecture.
Available as an Add-On Service or Module with:
Two development paths
Standalone service or application
A custom integration built as a standalone service uses the FormKiQ Document API to ingest, classify, and route documents from the source system. This approach is well suited to integrations where the source system has its own event or export model and the integration logic needs to live outside FormKiQ's deployment boundary — for example, a custom connector that polls a legacy system on a schedule or responds to events from an external platform.
FormKiQ module component
A custom integration built within FormKiQ's module architecture is deployed as a serverless component within your FormKiQ environment, following the same patterns as FormKiQ's standard modules. This approach is well suited to integrations that are tightly coupled to FormKiQ's processing pipeline — custom ingestion logic, transformation steps, or classification routines that need to operate as part of the document processing workflow rather than as an external caller.
Custom development as reusable platform components
Where custom development is built within FormKiQ's module architecture rather than as a standalone external integration, the resulting component benefits from the same versioning, upgrade compatibility, and serverless scalability as FormKiQ's standard modules. In cases where a custom module developed for one organization's requirements has broader applicability, FormKiQ may offer to incorporate it into the standard module catalog — partially offsetting development cost through the value added to the wider platform. This is discussed on a case-by-case basis as part of the professional services scoping conversation.
Document Archiving and Lifecycle Management
Define and enforce retention schedules, disposition rules, legal holds, and document lifecycles — with archiving to cost-effective cold storage when documents age out of active use.
Available with:
Governance controls across the full document lifecycle
This module provides the policy and control layer that organizations need to manage documents from creation through final disposition. Key capabilities include:
- Retention schedules — define how long documents must be kept based on document type, classification, or regulatory requirement, with automatic enforcement of the defined period
- Disposition — configure what happens when a document reaches the end of its retention period: scheduled destruction, transfer to archive, or routing to a disposition review workflow
- Legal holds — place a hold on specific documents or document sets to suspend destruction and modification, preserving them in their current state for litigation, audit, or regulatory inquiry, and release the hold when the matter concludes
- Check-out and check-in — allow users to check out documents for editing, preventing concurrent modifications and ensuring that changes are tracked against a known baseline before the document is checked back in
- Document lifecycle stages — define the stages a document passes through from creation to disposition, with lifecycle state visible in the document record and usable as a condition in Document Workflows
- Archiving and cold storage — automatically transition documents to lower-cost Amazon S3 storage tiers as they age out of active use, reducing storage costs while keeping documents retrievable through the FormKiQ API when needed