erp-sql

Skill: Finance and Operations SQL Access

Critical safety rules — read first

1. Confirm the Dataverse URL, selected access type, exact client IP or range, and access reason before requesting credentials. JIT access changes database access and firewall configuration even though the SQL check only reads. Verify the exact organization and linked ERP environment with the targeted Dataverse CLI check below before the request. This workflow uses Dataverse CLI verification instead of the overview's PAC check; PAC is not required. Every new grant invalidates existing SQL credentials for the same user in the same environment, including credentials used in Visual Studio, SSMS, or another SQL session. Disclose this and obtain explicit approval before each grant. The user must supply the IP address or range. Never discover it, suggest a range, or recommend a lookup source or command. If the user cannot provide it, stop before requesting credentials. The user must supply the JIT reason. Use the host's structured question tool if it has one, otherwise ask in chat. Keep any reason field empty, with no suggested/default answer. Wait for a meaningful, non-empty response; never invent, infer, or auto-fill the reason.
2. UDE-only (ErpDeploymentType = OnlineDev); the user must already have the environment System administrator (sysAdmin) role. USEs are not implemented or tested by this skill. Confirm eligibility before requesting a grant; never self-elevate. Reader is the only supported SQL access type. Obtain explicit approval for Reader access; never offer or request Writer, accept write-capable credentials, or escalate after a failure. Never broaden the approved IP scope without new explicit approval or execute direct ERP data changes; the helper only probes the connection and performs explicitly approved bounded table reads. Use supported business APIs for writes.
3. Never expose the password. Do not invoke the credential action through a tool that displays its response. Capture the managed CLI response inside Python, keep credentials in memory, and pass the password only in the sqlcmd child's SQLCMDPASSWORD environment. Never use -P, files, .env, chat, or logs for the password.
4. Never bypass TLS validation. Require encryption and certificate validation; do not add -C.
5. A credential response is not a successful connection. Require sqlcmd exit code zero and a matching database/login from the connection check. Do not claim success while a JIT operation or login is pending.
6. Default to a reusable session for interactive reads, starting with the first table request. Obtain approval to retain credentials in the owner process. Reuse only this conversation's session for the approved workspace/environment/role/IP scope. Do not close it merely because one read or agent turn finishes. Close on an explicit user request or known conversation end; idle timeout and expiry also end it. Never expose credentials, automatically renew access, or attach to another conversation's session.

This skill is an explicit opt-in exception to normal ERP OData/MCP reads, not a replacement for them. It connects to the ERP SQL database, not the Dataverse read-only TDS endpoint. A Dataverse authentication token is used to request temporary SQL credentials, not as the SQL password.

Feature eligibility: this skill supports unified development environments (UDEs) only, requiring the System administrator (sysAdmin) role in the environment. That prerequisite is separate from the SQL Reader role requested by both helpers. Supported business APIs, not direct SQL writes, belong in dv-data.

Current helper limitation: preflight accepts only ErpDeploymentType = OnlineDev. Microsoft's product database access documentation also covers unified sandbox environments (USEs), but that broader platform scope is not implemented or tested by this skill. Stop on any other deployment type; do not bypass the guard or guess a USE mapping.