CaRD Workspace for Azure
Sometimes the content is already in Azure and the question is not how to fill it up, but how to look inside again — without being able to change a thing.
Research on the storage itself
The CaRD Workspace for Azure is a web front end that works directly on an Azure storage account — no connector, no SAP and no second copy of the data. It shows containers and folders, lists blobs with their metadata and index tags, opens a detail view per object and allows individual downloads. Nothing more, and that is intentional.
The use cases are enquiry and evidence cases: content that came out of an archiving run or a decommissioning project and has to be retained for years; a storage account several systems have written into and nobody looks inside any more; an audit in which somebody has to demonstrate that a particular document exists. In all three, write access would be not merely unnecessary but a risk.
Read-only is therefore enforced, not configured. On top of that come hiding rules: containers or groups of objects nobody is meant to see are hidden and counted, so it is clear that something is missing. An attempt to bypass this — addressing a hidden object directly by name — comes to nothing and is refused with the name of the rule that applied.
For finding things there is a separate index layer: an indexer reads the metadata and index tags of the estate into a database of its own, derives the fields that actually occur and offers them as facets for filtering. Reconciliation runs in both directions; if a conspicuously large part of the estate disappears, the run aborts and reports it instead of quietly emptying the index.
At a glance
- Works directly on the Azure storage account — no connector required
- Read-only throughout, technically enforced
- Container and folder navigation with metadata and index tags
- Faceted search across the fields that actually occur in the estate
- Hiding rules with counting and bypass protection
- Its own index database — the estate itself is untouched
Why this matters
Content nobody can look into is not an archive.
- Retention without the ability to answer meets the deadline but not the purpose
- Answering enquiries through storage tools is error-prone and not traceable
- Granting write access just to look opens the chain of evidence
- Without facets every enquiry becomes a search in the dark
- An auditor does not accept “somewhere in that container” as an answer
When this solution fits
Deliberately narrow — and good at it.
- Content from archiving or system decommissioning
- Storage accounts several systems have written into
- Enquiry and evidence cases under a retention obligation
- Where no CMIS connector is involved, or is meant to be
- Where write access must be ruled out explicitly
See what is there
Metadata nobody else displays.
- Container and folder navigation
- Detail view with all metadata and index tags
- Facets from the fields that actually occur in the estate
- Search with several criteria, scoped to folder, container or everything
- Individual download with a sensible file extension
What stays hidden
Not everything in the storage account concerns everyone.
- Rules hide containers or groups of objects
- Hidden items are counted — the gap is visible, the content is not
- Direct access to a hidden object is refused
- The rule that applied is named, so the refusal is traceable
- A blocked container stays blocked even on direct access
The index
Its own database, untouched estate.
- The indexer reads metadata and tags into a database of its own
- The storage itself is neither changed nor extended
- Deletion reconciliation in both directions
- Conspicuously large losses abort the run instead of emptying the index
- The state per container can be inspected
Before go-live
Look first, build second.
- A read-only survey tool records the estate up front
- Result: containers, volumes, metadata fields actually populated
- From that follow the facets, the hiding rules and the effort
- Repeatable, so changes become visible
- Runs before every commissioning
Frequently asked questions
Does the Workspace for Azure need the CMIS connector?
No, and that is the difference from the Workspace for CMIS. This variant talks directly to the Azure storage account. It is intended for content where there is no connector, or where there is not meant to be one — typically legacy content from archiving and decommissioning.
Can anybody change or delete something through it?
No. Read-only is enforced and is not implemented as a setting somebody could flip. There is no function to upload, change or delete. That is precisely the purpose: give information without touching the chain of evidence.
How do you stop people seeing confidential material?
Through hiding rules at container and object level. Hidden items are counted so it stays visible that something is not being shown — hiding without any indication would be misleading. Anyone addressing a hidden object directly by name is refused, with the rule that applied named in the response.
Does the index change anything in the estate?
No. The indexer reads only and writes into a database of its own. The storage stays as it is — no additional tags, no markers, no helper files. During reconciliation a safeguard applies: if a conspicuously large part of the estate disappears, the run aborts with a message instead of emptying the index.
How do we know in advance whether this is worthwhile?
From a survey. A read-only tool runs across the storage account and shows which containers exist, how many objects they hold and which metadata fields are actually populated. From that follows which facets make sense and how much work setup involves — before anything is set up.
What is the status of the product?
The solution is built and verified against a real storage account — navigation, detail view, hiding, index run and search. It is young; for the first productive deployment we are deliberately looking for pilot customers and accompany the roll-out ourselves.
Does this match your project?
Talk directly to our consultants — no detours.