Dynamics GP User Types: Understanding Full, Limited, and Self Service Access

Table of Contents

Microsoft Dynamics GP utilizes a structured approach to user permissions, categorizing users into distinct types: Full, Limited, and Self Service. These user types act as foundational levels of access, determining the broad scope of activities a user can perform within the system. Understanding these types is crucial for system administrators when setting up security and assigning appropriate access levels to users based on their roles and responsibilities within the organization. The design aims to provide flexibility while ensuring data integrity and system security by limiting access to only what is necessary.

The user type assigned determines the fundamental access level to system functions, independent of the more granular role-based security. Think of the user type as a primary filter that dictates what kind of access is possible. Role-based security then refines this access, granting specific permissions to windows, reports, and tasks within the boundaries set by the user type. This layered security model allows administrators to define precise access rights for different users while maintaining a high-level structure.

Self Service User Type¶

The Self Service user type is designed for employees who need access to specific, limited functionalities, typically related to personal tasks or basic submissions. This user type represents the lowest level of access within Dynamics GP. It is primarily focused on allowing users to input information directly related to their own activities or initiate basic processes that require minimal system navigation or data manipulation.

Users assigned the Self Service type possess the ability to perform actions categorized under “Enter” access, but only for a very specific set of functions. This typically includes creating purchase requisitions, entering payroll timecards and expense reports, or submitting project timesheets and expenses. They are also often granted access to benefit self-service portals and can participate in workflow approval processes. The core purpose is data entry directly impacting their personal or limited departmental activities.

Crucially, Self Service users are typically restricted from viewing most system data outside of their own entered information or specific workflow tasks. They cannot access general inquiries, run standard reports, or utilize SmartLists to analyze data. Their interaction with the system is confined to specific entry windows designed for self-service purposes. This limitation is intentional, ensuring that sensitive company data remains protected and only accessible to users with higher permission levels.

This user type is ideal for a wide range of employees across an organization who need to interact with specific GP modules without requiring broad access to financial or operational data. Examples include sales staff submitting expenses, project team members entering time, or general employees requesting office supplies via requisitions. Their access is highly constrained to maintain a secure and streamlined environment.

Limited User Type¶

The Limited user type provides a greater level of access compared to the Self Service user, bridging the gap between basic data entry and full system interaction. Limited users inherit all the capabilities granted to Self Service users, allowing them to perform the same entry tasks such as submitting timecards or requisitions. This means they can also create certain documents and participate in workflows.

In addition to the “Enter” access shared with Self Service users, the Limited user type is granted “Inquire” access. This is a significant distinction, allowing them to view various inquiries, run standard reports, and utilize SmartLists. The scope of what they can inquire upon is still governed by role-based security, but the capability to view information is enabled at the user type level. This provides Limited users with the ability to review data relevant to their roles.

Limited users can typically view information related to customers, vendors, inventory, or financial summaries, depending on the specific roles assigned to them. This makes them suitable for roles that require monitoring, analysis, or reporting without the need to modify core system data or perform advanced setup tasks. They can pull data for decision-making or oversight purposes.

However, despite having “Inquire” access, Limited users do not have “Edit” access for most transactional or setup windows. They can view existing transactions or master records but cannot create new ones (outside of the specific self-service entry points), modify existing ones, or access setup windows. This limitation is fundamental to the Limited user type, ensuring that while they can access and review information, they cannot make changes that would impact system data integrity or configuration.

This user type is well-suited for departmental managers who need to view budgets, review team expenses, or run performance reports. It’s also appropriate for users in roles like credit control who need to inquire on customer balances or purchasing assistants who need to view vendor information and purchase order statuses. They have broader visibility than Self Service users but are restricted from editing core data.

Full User Type¶

The Full user type represents the highest level of access within Microsoft Dynamics GP. Users assigned the Full type have comprehensive permissions across the system, encompassing all levels of access: “Enter,” “Inquire,” and “Edit.” This means they can perform any operation that is technically possible within the software, subject only to the specific role-based security configurations assigned to them.

Full users can create, modify, delete, and post transactions in any module they have access to via their assigned roles. They can set up and configure system options, manage master records like customers, vendors, and items, and perform administrative tasks. They have complete control over the data and processes within the modules granted by their security roles. This level of access is necessary for core financial users, system administrators, and power users who are responsible for the day-to-day operation, configuration, and maintenance of Dynamics GP.

Given their extensive capabilities, Full users are typically roles such as Accountants, Controllers, System Administrators, and key departmental heads who require the ability to manage and modify data. They are responsible for tasks like posting ledger entries, running pay runs, managing inventory adjustments, or configuring workflow rules. Their access is powerful and carries significant responsibility regarding data accuracy and system integrity.

While the Full user type enables complete access, the actual permissions granted are still refined by role-based security. A Full user without specific roles assigned might not be able to access certain windows. However, if they are assigned the necessary roles, the Full user type ensures that they have the underlying capability to perform any allowed action within those windows (Enter, Inquire, Edit). They are not restricted by the high-level limitations imposed on Limited or Self Service users.

This user type requires careful assignment, as granting full access to too many users can pose security risks and increase the potential for errors. Best practice dictates assigning Full user types only to personnel who genuinely require broad access and edit capabilities to perform their job functions effectively.

The Dynamics GP Security Model: User Types and Role-Based Security¶

Understanding the interaction between user types and role-based security is key to effectively managing permissions in Dynamics GP. As mentioned, user types provide a fundamental filter. Role-based security then layers on top to grant specific access.

• User Type: Determines the type of access allowed at a high level (Self Service = Enter limited areas; Limited = Enter limited areas + Inquire broadly; Full = Enter, Inquire, Edit broadly). This is a ceiling on permissions.
• Role-Based Security: Consists of Roles and Tasks.
  • Tasks: Grant permission to specific Dynamics GP objects (windows, reports, scripts, etc.). A task might allow access to the ‘Sales Transaction Entry’ window or the ‘Trial Balance Report’. Tasks define the what.
  • Roles: Are collections of tasks. A role like ‘Accounts Payable Clerk’ might include tasks allowing entry of invoices, voiding invoices, and viewing vendor details. Roles group related permissions.

When a user logs in, Dynamics GP checks their assigned user type and their assigned roles.

1. The user type determines the maximum level of access (Enter, Inquire, Edit) the user can have across the system.
2. The assigned roles grant permission to specific objects (windows, reports).

A user can only access an object and perform an action if both their user type and their assigned roles permit it. For example:

• A Self Service user with a role that includes a task for ‘Sales Transaction Entry’ window access will not be able to open the window, because the Self Service user type does not permit access to standard transaction entry windows (only specific self-service windows).
• A Limited user with a role that includes a task for ‘Vendor Setup’ window access will not be able to open the window, because the Limited user type does not permit ‘Edit’ access to master record setup windows.
• A Limited user with a role that includes a task for the ‘Customer Summary Inquiry’ window will be able to open the window, because the Limited user type permits ‘Inquire’ access, and the role grants access to that specific inquiry window.
• A Full user with a role that includes a task for the ‘General Ledger Transaction Entry’ window will be able to open the window and enter/edit transactions, because the Full user type permits ‘Edit’ access, and the role grants access to that specific entry window.

This layered approach ensures that even if a role is inadvertently assigned that could grant edit access (e.g., a role designed for Full users), a user with a Limited or Self Service type will still be restricted by their fundamental user type limitations.

Practical Considerations and Testing¶

The interaction between user types and the vast number of windows, reports, and tasks in Dynamics GP can sometimes lead to unexpected behavior. As the original KB article notes, it’s easy to anticipate a user having access to something only to find their user type prevents it. This is why thoroughly testing the security setup for each user type is critically important, especially for Limited and Self Service users.

When configuring security for a user with a Limited or Self Service type, administrators should:

1. Assign the user type and relevant roles/tasks.
2. Log in as that specific user (or have the user test) and navigate through the processes they are expected to perform.
3. Verify that they can access the necessary windows and reports.
4. Verify that they cannot access windows or perform actions they are not permitted to.
5. Pay close attention to third-party products, as their integration points may interact with Dynamics GP security in unique ways.

This testing phase helps identify any discrepancies between the intended access and the actual access granted by the combined effect of user type and role-based security. It is a crucial step in ensuring that users have the tools they need to perform their jobs without having excessive permissions that could compromise system security.

The security configuration window in Dynamics GP (Microsoft Dynamics GP >> Tools >> Setup >> System >> User Security) allows administrators to assign user types and roles. The Security Task Setup and Security Role Setup windows (Microsoft Dynamics GP >> Tools >> Setup >> System >> Security Tasks and Security Roles) are used to define the granular permissions within roles and tasks. Regularly reviewing security assignments and testing them is a best practice for maintaining a secure Dynamics GP environment.

Summary of User Types and Access Levels¶

Here is a simplified overview of the capabilities associated with each user type:

User Type	Enter Access (Specific Self-Service)	Enter Access (Standard Transaction)	Inquire Access (Reports, SmartLists)	Edit/Delete/Setup Access	Typical Use Cases
Self Service	Yes	No	No	No	Employees submitting time/expenses, requisitions
Limited	Yes	No	Yes	No	Managers viewing reports, reporting users, inquiry
Full	Yes	Yes	Yes	Yes	Accountants, Administrators, Power Users

It’s important to remember that “Yes” in this table indicates the potential capability granted by the user type. The user still needs specific security roles and tasks assigned to access particular windows or reports within that category. For example, a Limited user can use SmartLists, but they need a role that grants access to specific SmartList objects.

Conclusion¶

Effectively managing user access in Microsoft Dynamics GP is a critical administrative task. By understanding the fundamental differences between Full, Limited, and Self Service user types, administrators can establish a secure foundation for their system. These user types, combined with the granular control offered by role-based security, allow organizations to tailor user permissions precisely to job requirements. Regular review and testing of security configurations are essential to ensure that users have appropriate access, protecting valuable business data while enabling operational efficiency. Implementing and maintaining a robust security model is an ongoing process that significantly contributes to the overall health and integrity of the Dynamics GP environment.

Do you have experience configuring security in Dynamics GP? What challenges have you faced when setting up Limited or Self Service users? Share your thoughts and tips in the comments below!