# ERP Database Read-Only Access Request Form

> Source: https://netray.co/tools/erp-database-read-only-access-request-form
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A scoped, time-boxed request for a read-only SQL login or reporting role on an ERP database, with owner approvals.

## Category

erp-operations

## Audience

- Database administrator
- ERP administrator
- IT security
- ERP analyst

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Applicant

**Key:** applicant

**Type:** text

**Default:** Mei Lin Tan

#### Job role

**Key:** role

**Type:** text

**Default:** Finance systems analyst

#### Line manager

**Key:** manager

**Type:** text

**Default:** Rahul Verma

#### Database and server

**Key:** database

**Type:** text

**Default:** ERP_PROD on SQL01 (use a reporting replica if available)

#### Scope of access

**Key:** scope

**Type:** select

**Options:**

- Named views only
- Named tables only
- Whole schema read only
- Reporting replica only

**Default:** Named views only

#### Objects needed

**Key:** objects

**Type:** textarea

**Default:** Views for sales invoices, purchase receipts and item master. No payroll, HR or banking tables.

#### Business purpose

**Key:** purpose

**Type:** textarea

**Default:** Month end reconciliation of receipts to GL and ad hoc margin analysis.

#### Start date

**Key:** start

**Type:** date

**Default:** 2026-11-01

#### Expiry date

**Key:** expiry

**Type:** date

**Default:** 2027-01-31

#### Authentication

**Key:** method

**Type:** select

**Options:**

- Windows or SSO group
- SQL login
- Service account

**Default:** Windows or SSO group

**Blocks:**

#### Read-Only Database Access Request

**Body:** Applicant: {{applicant}}
Role: {{role}}
Line manager: {{manager}}

#### Access requested

**Body:** Database: {{database}}
Scope: {{scope}}
Authentication: {{method}}
Start: {{start}}
Expiry: {{expiry}}

Objects needed:
{{objects}}

#### Purpose

**Body:** {{purpose}}

#### Conditions

**Table:**

**Columns:**

- Condition
- Acknowledged

**Rows:**

**0:** Access is read only, no INSERT, UPDATE, DELETE or DDL

**0:** Long running or unfiltered queries on production are not permitted

**0:** Extracts containing sensitive data are stored only in approved locations

**0:** Credentials are not shared

**0:** Access is reviewed at expiry and removed if not renewed

#### Approvals

**Signatures:**

- Applicant
- Line manager
- Data owner
- DBA
- Information security

**Notes:** Adapt to your own access control and segregation of duties policy. Where possible grant access through a group, to views, on a reporting replica. This is a starting template, not legal advice.

## Content

**Intro:** Analysts need to query the ERP database, and administrators need to know who can see what. This form records a narrow, expiring, read-only grant instead of an open-ended db_datareader on production.

**Sections:**

#### How to use the form

**Body:** Pick the narrowest scope that does the job. Named views beat named tables, and named tables beat the whole schema. Say what the person will do with the data, because the purpose decides which objects and which environment are appropriate. Set an expiry date even for ongoing roles, so access is reviewed rather than forgotten.

#### Least privilege in practice

**Body:** Read-only access still carries risk. A wide SELECT can lock or slow a busy ERP, expose cost and personal data, and move data outside the company. Prefer a reporting replica, a read-committed snapshot or a data warehouse copy for analysts. Grant through an Active Directory or SSO group so that offboarding removes access automatically.

**Bullets:**

- Views that hide sensitive columns
- A replica or snapshot instead of production
- Group based grants, not individual logins
- Expiry and periodic recertification

#### What the DBA should check

**Body:** The DBA confirms the object list exists, that the grant is SELECT only, that row level or column level restrictions are in place where needed, and that query governor or resource limits protect the production workload. The form gives them a record to attach to the change ticket and to produce for auditors.

#### Common mistakes

**Body:** Frequent errors are granting sysadmin or db_owner to save time, reusing a shared reporting login, leaving access active after a role change, and approving access without stating which tables hold personal, payroll or export controlled data. A short form and a fixed expiry fix most of these.

**Cta:** If you want people to ask questions of ERP data without handing out database logins, we can help you set up read-only, role-aware access that shows the underlying query and stays inside your network.

**Faq:**

#### Is read-only access safe on a production ERP?

**Answer:** It is safer than write access but not free of risk. Unfiltered queries can cause locking or heavy load, and the data may be sensitive. Use a replica or snapshot and resource limits where you can.

#### Should I grant access to tables or views?

**Answer:** Views are usually better. They hide sensitive columns, survive table changes and give you one place to apply filters such as company or plant. Direct table access is a fallback.

#### How long should access last?

**Answer:** Match it to the business need. Project work often fits 90 days. Ongoing roles can be 12 months with recertification. The point is that expiry forces a conscious review.

#### Who must approve?

**Answer:** At minimum the line manager and the data owner, then the DBA for technical execution. Add information security for sensitive data or external users such as contractors.

## Search terms

database access request form, read only access request template, erp database access form, sql server read only login request, reporting user access request, least privilege access request template, data access approval form

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json