Solutions · Repository connectors

Search line-of-business databases for FOI and ATIP requests

A case register, a complaints log, a licensing or ticketing system — expose one SQL Server or Azure SQL view, and each row a coordinator selects is captured as a self-contained record of the columns you chose, with the row id, the modified stamp and a SHA-256 on record. Built into AccessPoint, read-only, and every value a user types reaches the database as a parameter.

Start Free Trial Request a Demo

Some of the most-requested records aren't documents at all. The responsive record for a by-law complaint, a business licence, an inspection or a service ticket is a row in a line-of-business system — and the usual way to get it into a request is a screenshot, a report someone runs by hand, or a spreadsheet export that loses the record's identity the moment it's saved.

The SQL database connector is built into the AccessPoint API. A database administrator prepares a view that presents exactly the columns the access office may see; an AccessPoint administrator registers the server, database, schema and view, and names an id column, a name column, an optional modified column and up to 50 body columns. The view is browsed as a single folder, its rows listed by name and searched by name — and by date, when a modified column is named — and the details flyout shows a row's columns before anything is captured. A captured row becomes one HTML record: the name as its heading, a source line naming the view, server, database, record id and capture time, then the body columns in your order. It then converts to PDF, is indexed and is scanned for redactions like any uploaded file.

The connector signs in with the API's system-assigned managed identity, granted db_datareader or SELECT on the view, so there is no secret anywhere — or, for a SQL login, a database in another tenant or a server that only accepts SQL authentication, with a connection string held as a Key Vault reference. Connections are encrypted with the server certificate validated, and the connector never writes. It declares the Application identity mode: AccessPoint's permission rule is the gate, and row-level security in the database applies to the connector's identity, not to the coordinator. Nothing about the user reaches the database — its audit shows the connector's identity under the application name AccessPoint SQL view connector — while AccessPoint records who captured which row, for which case and why. There is no service to host; the connector checks the view's columns once per call, which matters only for a database that bills per query.

Sound familiar?

Three moments every office that answers requests for database records recognizes.

The record that is a row

A requester asks for every complaint filed about one property. The answer is forty rows in the by-law system, and the only way out of it is a screenshot of each one.

The export that lost its identity

Someone runs a report to Excel, filters it, and attaches it. Six months later, nobody can say which rows were in the system that day or how they were chosen.

Too much in the extract

IT exports the whole table because it's quicker — including columns the access office was never meant to see, now sitting in the request file.

What to look for when an FOI system reaches a SQL database

Whatever you use, these are the questions to ask before a line-of-business database is opened to the access office.

A view, not the tables The database team should decide exactly which columns are exposed, in a view they own — the connector reads only the columns you name.
Parameters, never spliced SQL Every value a user types — search text, dates, ids — should reach the database as a parameter, with every table and column name checked against the schema first.
No stored password where an identity will do A managed identity with read rights on the view means no password at all; where a SQL login is unavoidable, the connection string belongs in Key Vault.
The row's id and version on the record A modified column recorded as the source version, so a changed row is captured again and an unchanged one isn't duplicated on the case.
A readable, redactable record A row should become a document a reviewer can read, redact and release — not a CSV fragment that loses its column names.
Read-only, encrypted connections Encryption required with the server certificate validated, and an account that can read but never write.

How the SQL database connector works

Built into the AccessPoint API, configured in Settings, shaped by a view you control.

Built in, checked on save

Register the server host name, database, schema, view and columns. Saving validates every name against the view's schema, so a typo or a missing grant is refused before anyone sees the tile.

Browse and search rows

Rows are listed in id order and paged. Search matches the name column, with characters such as % and _ matched literally; a modified column adds the date filter.

Each row as a record

A capture renders one HTML file per row — heading, source line, record id and modified stamp, then your body columns, every value HTML-encoded — and sends it through the same pipeline as an uploaded file.

A hash on every capture

The SHA-256 is computed over the record AccessPoint stores, so provenance always reads Verified. It attests to the copy; the capture time in the source line makes each capture its own file.

Versions from your modified column

Name a modified column and its value becomes the source version: a row changed since its last capture is captured again; an unchanged one on the same case is skipped as already captured.

Guard rails

With managed identity the host must be an Azure SQL endpoint, AccessPoint's own SQL server is refused, and schema, view and column names must be plain identifiers — letters, digits and underscores.

See it in AccessPoint

Real screens from the product, running in a Microsoft 365 tenant. Click any one to enlarge.

The Add connector form listing Azure Blob container, MCP search/fetch server, SQL view, CMIS 1.1 repository and Remote connector Click to enlarge
A built-in kind. Registered in Settings in a few fields, with nothing extra to host.

Chain of custody

The row as it stood, on the day you took it

A screenshot proves nothing about where it came from. A captured row carries its own source line — the view, the server, the database, the record id and the UTC time it was taken — inside the record, and the document's Source details hold the same facts, with the modified stamp as its version, who captured it, when, and for which case. An audit-ledger entry is written for every capture, and the provenance columns travel with a tenant export. Files the row merely points at are not fetched, so what the case holds is exactly what the view returned.

Read in place The database is read where it lives; the rendered record is stored in your tenant's own storage.
Attributed on your side The database sees one service identity; AccessPoint records the person, the case and the purpose.
No per-connector fee Repository connectors are included in every AccessPoint plan.

From view to case

The path for a complaints or licensing database:

  1. Create a view that exposes exactly what the access office may see, with a unique id column, a name column and, ideally, a modified date/time column. Index the id, name and modified columns.
  2. Create a database user for the AccessPoint API's managed identity and grant it db_datareader or SELECT on the view — or store a connection string in Key Vault.
  3. In Settings → Foundations → Repository connectors → Add connector, choose SQL view and enter the server, database, schema, view and columns. Save checks every column against the view.
  4. Run Test connection, then choose who sees the tile — coordinators by default.
  5. On a case, open Add from…, choose the database, search by name or date, check a row's columns in the details flyout, and add it. Larger selections run as a background job.

Go deeper

Repository connectors Every connector, how capture works, and the chain of custody behind it. Connectors in the docs Registering, testing and operating connectors, step by step. Municipal & local government By-law, licensing and service records — and the small office that answers for all of them. MCP search server connector When a line-of-business system already publishes a search server for Copilot. FOI request management The full request lifecycle the record belongs to — deadlines, collection, redaction, release. Security & data sovereignty Where captured records live, who can see them, and what never leaves your tenant.

SQL Database Connector Questions

How can we capture records from a line-of-business database for an FOI request?
With AccessPoint's SQL database connector. Your database team creates a view of the case register, complaints log, licensing or ticketing system that presents only the columns the access office may see; an administrator registers it in AccessPoint. Coordinators then search the rows by name or date from any case and capture the ones they need. Each row becomes a self-contained HTML record — converted to PDF, indexed and redactable like any upload — with the row id, the modified stamp and a SHA-256 recorded on the document.

Which databases does the SQL connector support?
SQL Server and Azure SQL, through one view (or table) per connector. With the API's managed identity the server must be an Azure SQL endpoint; with a connection string held as a Key Vault reference, any SQL Server the AccessPoint App Service can reach — including one that only accepts SQL logins. AccessPoint's own database server is refused as a source.

What permissions does it need, and can it change data?
It needs read access only: db_datareader on the database, or SELECT on the view, for the AccessPoint API's managed identity — or the login in your connection string. The connector never writes. Every value a user types reaches the database as a parameter, every schema, view and column name comes from the registration and is checked against the database's own catalogue, and connections are encrypted with the server certificate validated.

Does it fetch files the database points to?
No. The captured record is a rendering of the columns you choose; attachments stored outside the row are not fetched, and there is no Open in source link because a row has no URL. If the files live in Azure Blob Storage or on a network share, those connectors capture them with their own provenance.

Does database data leave our tenant?
No. The connector runs inside the AccessPoint API in your own Azure subscription, reads the view where it lives, and stores the rendered record in your tenant's own storage. The browser never connects to the database, nothing passes through Realizer, and no information about the user is sent to the database — attribution is recorded on the AccessPoint side.

What does the SQL database connector cost?
Nothing extra from Realizer: repository connectors are included in every AccessPoint plan, with no per-connector fee. The connector runs inside the AccessPoint API, so there is no service to host. It checks the view's columns once per call — one extra catalogue query — which is worth knowing only for a database that bills per query.

Flat annual pricing, published in full. Every feature in every size — access requests, privacy impact assessments, breach response, complaints, video & audio redaction, the public portal, repository connectors, and AI Assist. No per-user or per-module fees.

  • Under 500 employees$2,990/yr
  • 500–1,999 employees$7,990/yr
  • 2,000–9,999 employees$14,990/yr
  • 10,000+ employees$29,990/yr

See full pricing Build the business case

Capture the Row, Not a Screenshot.

Try AccessPoint free for 30 days in your own Microsoft 365 tenant — repository connectors included, no per-connector fee.

Start Free Trial Request a Demo