nav2009-permissions-securitylisted

Expert guidance on the Microsoft Dynamics NAV 2009 security and permissions model — diagnosing "you do not have permission to Read/Insert/Modify/Delete/Execute" errors, designing role-based access via NAV Roles (Permission Sets), understanding object permissions (Read, Insert, Modify, Delete, Execute, indirect), security filters for record-level access control, Windows vs Database login modes, and NAV↔SQL login/permission synchronization including the Standard vs Enhanced SQL security models. Use when a user hits a "you do not have permission" error in NAV 2009, when designing or auditing Roles for Sales/Purchasing/Finance/Posting-only users, when a NAV user cannot log in or records are invisible, when setting up security filters by Responsibility Center or company, or when troubleshooting NAV↔SQL login synchronization.
whobat/AI-Agent-skills · ★ 0 · AI & Automation · score 73

Install: claude install-skill whobat/AI-Agent-skills

# NAV 2009 Permissions & Security Expert guidance for **Microsoft Dynamics NAV 2009** security: the two-layer license/permission model, Roles, object rights, security filters, login modes, and SQL security synchronization. This skill is knowledge-only; detailed tables and error-cause mappings live in [REFERENCE.md](REFERENCE.md) — consult it before diagnosing a non-trivial permission problem or designing a Role set. ## Platform facts (don't guess against these) - **Two layers**: the NAV **license (.flf)** gates which objects exist and can run at all; **permissions** (Roles) gate which users may use the licensed objects. A "permission" error can actually be a license-range issue — distinguish them before changing Roles. - **Roles = Permission Sets**: NAV 2009 uses the term *Role* (tables `Permission Set` and `Permission`). A Role is a named bundle of per-object rights. Users receive Roles through the **User Role** assignment (Tools → Security in Classic, or the User card). The **SUPER** Role grants full access to all objects; **SUPER (DATA)** grants full data access but excludes object design. - **Object rights**: each permission record covers one object type (TableData, Table, Form, Report, Codeunit, Page, XMLport, etc.) with individual flags for **Read, Insert, Modify, Delete, Execute** plus an **Indirect** qualifier — indirect means the user may touch the object only through other C/AL code, never directly. - **Security filters**: an optional filter str