Unlock Dynamics GP Security: FAQs on Advanced & Field Level Protection

Table of Contents

Ensuring robust security within an Enterprise Resource Planning (ERP) system like Microsoft Dynamics GP is paramount for data integrity, regulatory compliance, and business continuity. This document delves into frequently asked questions regarding the setup and utilization of two critical security components: Advanced Security and Field Level Security. Understanding these features empowers administrators to fine-tune user access and protect sensitive information effectively within Dynamics GP environments.

The insights provided here are particularly relevant for Microsoft Dynamics GP users and system administrators. The original knowledge base article number associated with this information is 894705, providing a historical context for these security discussions. A comprehensive understanding of these security layers is essential for maintaining a secure and efficient operational environment.

Advanced Security¶

Question 1: Where is the Advanced Security module located in Microsoft Dynamics GP?¶

Answer 1: In Microsoft Dynamics GP 9.0 and earlier versions, the Advanced Security module could be accessed by navigating through Tools > Setup > System > Advanced Security. This provided a centralized interface for managing various security aspects. However, it’s crucial to note that Advanced Security was gradually phased out with the introduction of Dynamics GP 10.0.

Dynamics GP 10.0 brought significant enhancements to the security model, introducing a more modern, role-based security system. Consequently, Advanced Security is no longer available in versions of Dynamics GP higher than 10.0, as its functionalities were superseded and integrated into the new role-based architecture. This shift aimed to streamline security management and align with modern ERP security paradigms.

Question 2: What are the differences between Advanced Security and Standard Security?¶

Answer 2: The fundamental differences between Advanced Security and Standard Security in Microsoft Dynamics GP lie in their approach to managing user permissions and interface. Standard Security traditionally relied on separate, distinct dialog boxes, requiring administrators to navigate multiple screens to configure security for individual users or user classes. This method involved knowing the precise names of dialog boxes and their associated series, making it a more fragmented and less intuitive process. Furthermore, managing security for modified, alternate, or modified alternate windows in Standard Security often necessitated changing views, adding complexity.

Advanced Security, in contrast, introduced a more streamlined and efficient security management experience. It featured an explorer-style interface, allowing administrators to control various types of security concurrently from a single, unified dialog box. This included comprehensive management for multiple users, companies, and classes, as well as integrated SmartList security. The user-friendly interface significantly simplified the process of setting and reviewing security permissions, particularly for complex environments with numerous custom modifications.

Here’s a comparison table highlighting the key differences:

Feature/Aspect	Standard Security	Advanced Security (GP 9.0 and earlier)
Interface	Separate dialog boxes for different security types	Explorer-style, unified interface
Management Scope	Single user or user class at a time	Multiple users, companies, and classes simultaneously
SmartList Security	Managed in a separate dialog box	Integrated within the Advanced Security interface
Customizations	Requires changing views for modified/alternate windows	Direct access to modified/alternate resources without view changes
Navigation Model	No direct navigation model integration	“By Menu” view allows security based on navigation model
Hierarchy	Less hierarchical, granular control often isolated	Hierarchical control; changes roll down to child resources automatically
Efficiency	More time-consuming, less intuitive for complex setups	More efficient, streamlined for comprehensive security management

This table illustrates how Advanced Security offered a significant leap forward in usability and efficiency compared to its standard counterpart.

Question 3: What are some of the benefits of using Advanced Security?¶

Answer 3: Advanced Security offered a multitude of benefits that significantly improved the management and flexibility of security within Microsoft Dynamics GP (up to version 9.0). One primary advantage was its ability to configure security settings for multiple users, companies, and user classes simultaneously. This eliminated the tedious task of applying individual security changes across numerous entities, drastically saving administrative time and reducing the potential for inconsistencies. Importantly, when class-level changes were made, Advanced Security was designed not to overwrite specific user-level modifications, allowing for a blend of standardized class permissions and tailored individual access.

Another key benefit was the option to set security permissions based on the system’s navigation model, through the “By Menu” view. This intuitive approach allowed administrators to grant access to functionalities as users would naturally encounter them in the system, making the security setup process more logical and easier to verify. Furthermore, Advanced Security provided a specialized “By Alternate, Modified, and Custom” view. This view exclusively displayed customized resources, simplifying the control over access to unique modifications and ensuring that custom developments were appropriately secured without sifting through standard resources.

Advanced Security also provided powerful utilities for security replication and verification. It allowed administrators to quickly copy security settings from one user or company to another, accelerating the deployment of consistent permissions across the organization. For instances where class security needed to be reapplied to users, the “Revert First” option enabled a clean reset of user-level settings before rolling down class configurations, ensuring conformity. Conversely, it could also roll up a user’s security settings to a class, aiding in the creation of new class templates based on functional user profiles. The system also featured capabilities to revert user security settings to their initial state, providing a safety net for configuration errors, and to verify security settings for validity, ensuring all pointed customizations actually existed and were accessible.

Additional functionalities included the ability to export and import security settings using .xml files, which was invaluable for system backups, migrating settings between different Dynamics GP environments, or deploying standardized security configurations. Selective printing of security settings for specific users, companies, or classes facilitated documentation and audit processes. Perhaps one of its most innovative features was an interactive dialog box designed to identify and rectify security problems on the fly. This interactive tool could grant temporary or permanent window access to a user without requiring them to log out and back in or switch computers, although it required a system password for making changes and was controllable in earlier versions of GP (Great Plains 8.0 and Dynamics GP 9.0, where it was off by default). These capabilities collectively made Advanced Security a robust and indispensable tool for system administrators.

Question 4: Where do I find my alternate and modified windows and reports?¶

Answer 4: Locating alternate and modified windows and reports within Advanced Security was designed to be straightforward, leveraging the system’s hierarchical structure. When using views such as “By Menu” or “By Dictionary,” alternate and modified versions of a resource were displayed directly underneath its original, standard counterpart in the tree structure. To access them, an administrator would first navigate to the original window or report and then expand its node. This expansion would reveal the various dictionaries in which that specific resource existed, allowing for the selection of the desired version (e.g., the standard, an alternate, or a modified one). This direct method provided immediate visibility into all available versions of a resource, simplifying the management of customized environments.

Alternatively, Advanced Security offered a specialized view specifically for these customized resources. By clicking the down arrow next to the view selector, administrators could choose the “By Alternate, Modified and Custom” view. This dedicated perspective filtered the entire security tree to show only those resources that had been customized, modified, or presented as alternate versions. This targeted view significantly streamlined the process of configuring security for custom developments, ensuring that administrators could focus solely on the unique elements of their Dynamics GP implementation without distraction from standard, unmodified components.

Question 5: How do the “Grant Security: All Alternate windows and reports” and “Grant Security: All Modified windows and reports” options work?¶

Answer 5: These specific “Grant Security” options in Advanced Security were intelligent features designed to streamline the process of re-granting access to customized resources after it had been previously denied. They became active when an administrator was in the process of re-enabling access to a particular resource. When the “Alternate” option was selected, Advanced Security would first check if a single alternate window or report existed for the resource in question. If a unique alternate version was found, the system would automatically select it in preference to the original dictionary version, ensuring that users were directed to the customized experience. However, if multiple alternate windows or reports were present for a single resource, Advanced Security would default to the original version, requiring manual selection for the specific alternate needed.

Following the selection of a dictionary (either the original or an alternate), the “Grant Security: All Modified windows and reports” option came into play. If this option was chosen and a modified version of the selected window or report existed, Advanced Security would automatically select that modified version. This layered approach meant that administrators could efficiently grant access to the most relevant, customized versions of resources with minimal manual intervention. These options significantly reduced the administrative burden, especially in environments with extensive customizations, by intelligently pre-selecting the most appropriate versions of windows and reports for user access.

Question 6: How can I speed up changes by User Class?¶

Answer 6: When performing security changes via User Class in Advanced Security, administrators can significantly impact the performance and responsiveness of the system. Unlike user-specific changes, class-level modifications are not tied to a single company; instead, they are automatically propagated to all companies associated with every user assigned to that particular class. This broad application can be a powerful efficiency tool but also potentially resource-intensive, particularly in large environments.

To optimize performance during these class-level security adjustments, administrators had the option to clear the “Display class changes on affected users” checkbox located in the Advanced Security Options window. By deselecting this option, the system would no longer attempt to visually render or immediately reflect the class changes on individual user profiles as they were being made. While this meant the administrator wouldn’t see the immediate impact of their changes, the modifications would still be correctly applied to all affected users and companies once the “OK” or “Apply” button was clicked. This approach maintained the integrity of the security application process but prevented the interface from being bogged down by real-time visual updates, thereby improving the perceived speed of operations during class configuration.

Question 7: What does it mean when the **No Dictionary option is selected for a window or for a report?**¶

Answer 7: When the “No Dictionary” option was selected for a window or report within Advanced Security, it served as a critical indicator that the system was encountering a discrepancy regarding the resource’s availability. This message typically signified one of two primary conditions. Firstly, it could mean that the security record, which defines access permissions, was pointing to a dictionary (a collection of application components, like forms and reports) that was not currently loaded or accessible on the computer where Microsoft Dynamics GP was running. This often occurred if a custom dictionary, a third-party add-on, or even a core Dynamics GP dictionary was missing, corrupted, or not properly configured in the current client installation.

Secondly, the “No Dictionary” status could indicate that a modified version of a window or report, which the security setting was configured to reference, simply did not exist on the current computer. This might happen if customizations were deployed to one environment but not another, or if a modified report was referenced by security but the corresponding modified report file was not present in the application’s directory. In both scenarios, the “No Dictionary” message highlighted a potential broken link in the security configuration, alerting administrators to an issue that could lead to unexpected behavior or access restrictions for users trying to utilize that specific resource. Troubleshooting would involve verifying dictionary installations, customization deployments, and path configurations.

Question 8: Can I use regular security after Advanced Security has been used?¶

Answer 8: Yes, it was entirely possible and common to use both regular (Standard) security and Advanced Security in conjunction within Microsoft Dynamics GP, provided they were not open simultaneously. The two systems were designed to coexist, allowing organizations to leverage the enhanced features of Advanced Security for complex configurations while still utilizing the more basic Standard Security for simpler adjustments if preferred. This flexibility allowed administrators to transition gradually or to manage specific aspects of security using the tool they found most appropriate.

However, a critical operational guideline was to ensure that only one of the security configuration windows was open at any given time. If an administrator made changes in one security interface (e.g., Advanced Security) while the other (Standard Security) was also open, it could lead to potential conflicts, overwriting of settings, or data corruption in the security tables. Therefore, the best practice was always to close one security window before opening or making changes in the other, safeguarding the integrity of the security configurations and preventing unforeseen issues.

Question 9: How can I clear the activity records for Advanced Security?¶

Answer 9: Occasionally, users might encounter an error message stating, “Another user is using advanced security. Try again later,” even when no other users appear to be logged into the system or actively using Advanced Security. This common issue arises because a user might not have exited the Advanced Security module correctly, leaving an lingering “activity record” in the database. This record effectively locks the module, preventing other administrators from accessing it until the perceived activity is cleared. To resolve this, two primary methods could be employed.

Method 1: Graceful Exit through the Application

1. Start Microsoft Dynamics GP: Launch the application as usual.
2. Sign In as the Stale User: Log in using the exact user ID and company information that is indicated in the activity record. This step is crucial as it allows the system to recognize and release the lock associated with that specific session.
3. Access Advanced Security: Navigate to Tools > Setup > System > Advanced Security.
4. Close the Window: Simply close the Advanced Security window. This action typically triggers the system to properly record the exit and clear the corresponding activity record from the database.

Method 2: Direct Database Intervention (SQL)

1. Access SQL Management Tools: Start Microsoft SQL Query Analyzer or SQL Server Management Studio. This method requires direct database access and appropriate permissions.

2. Execute SQL Script: To forcefully delete the Advanced Security activity record, execute the following SQL script against your Dynamics GP DYNAMICS database. This script specifically targets the SY_ResourceActivity (SY00801) table, where activity records for various system resources are stored.

   delete from DYNAMICS..SY00801 where RSRCID = 'WDC_ADVSEC_SECURITY'
   

   This SQL command directly removes the entry that marks Advanced Security as “in use,” thereby unlocking the module for other administrators. Caution should always be exercised when directly manipulating database records; it is advisable to perform a database backup before executing such commands in a production environment.

Field Level Security¶

Question 1: Why am I denied access to the Customization Status window?¶

Answer 1: Access to the Customization Status window in Microsoft Dynamics GP is a critical administrative function, as it displays all installed dictionaries and allows for the temporary disabling of Dexterity triggers used by each. This window also provides the capability to print a comprehensive report of all registered triggers within the system, making it a powerful tool for troubleshooting and managing system customizations. However, administrators might occasionally find themselves denied access to this window, even if their system administrator has previously confirmed that the necessary security permissions are in place.

This denial typically occurs under a very specific condition: when Field Level Security (FLS) is registered and at least one Field Level Security ID is actively enabled for the current user or the current company. This behavior is not a bug, but rather a deliberate safeguard built into the system. The purpose of this security measure is to prevent any user from bypassing the applied Field Level Security restrictions. If a user were able to access the Customization Status window and disable the Dexterity triggers associated with FLS, they could potentially circumvent the granular security levels that have been meticulously configured, compromising data integrity and security policies. Therefore, denying access to this window when FLS is active ensures the ongoing enforcement of field-level protections.

Question 2: What is Field Level Security?¶

Answer 2: Field Level Security (FLS) in Microsoft Dynamics GP is an advanced security feature designed to extend and enhance the granularity of security options beyond standard window-level permissions. It significantly increases the control administrators have over specific data entry points, forms, windows, and even individual fields within the application. Unlike broader security settings that govern access to entire modules or windows, FLS allows for highly targeted application of security policies.

With Field Level Security, administrators can implement a variety of protective measures. For instance, passwords can be applied to specific forms and windows, requiring an additional authentication step before a user can proceed. Alternatively, access to certain forms or windows can be entirely blocked, presenting a warning message to any user attempting to open them. More granularly, FLS empowers administrators to apply passwords directly to individual fields, ensuring that sensitive data points require extra verification before modification. Beyond password protection, FLS can be configured to hide fields from view, disable fields to prevent data entry, or lock fields to prevent any changes, offering a comprehensive suite of tools for securing critical information at the most granular level. This capability is essential for compliance with data privacy regulations and for enforcing strict internal control policies.

Question 3: What happened to Field Level Security Scripting?¶

Answer 3: Field Level Security Scripting, a component that once offered enhanced customization capabilities within FLS, has been discontinued and is no longer distributed or registrable in Microsoft Dynamics GP. This significant change was a direct response to evolving security paradigms and the “Trustworthy Computing” program initiated by Microsoft. The scripting functionality, while powerful, was identified as a potential security vulnerability.

The concern arose because malicious users could theoretically exploit the scripting capabilities to bypass existing application security measures. Such exploitation could lead to unauthorized access, manipulation, or retrieval of sensitive data, posing a significant risk to data integrity and system security. In line with the principles of the “Trustworthy Computing” initiative, which prioritizes security, privacy, and reliability, the scripting functionality was removed. This decision aimed to mitigate the potential for these security risks, ensuring a more secure and robust environment for all Microsoft Dynamics GP users by eliminating a vector that could be used for malicious purposes.

Question 4: Can I create functionality for row level security with Field Level Security?¶

Answer 4: Prior to the removal of the scripting functionality from Field Level Security (FLS), it was indeed possible to implement rudimentary forms of row-level security. This meant that administrators could, to some extent, control which specific data rows a user could view or modify based on certain criteria, extending protection beyond just fields. However, with the deprecation of FLS scripting due to security concerns, this direct capability within FLS is no longer available.

To achieve row-level security functionality in current versions of Microsoft Dynamics GP, administrators must now turn to more robust customization tools. The primary methods for creating such advanced security rules involve customizing Microsoft Dynamics GP using either Microsoft Visual Basic for Applications (VBA) or Dexterity. These development environments allow for the creation of custom logic that can dynamically filter or restrict data access at the row level based on user roles, company affiliations, or other business rules. This approach, while requiring more development expertise, provides a more secure and flexible framework for implementing complex data access restrictions.

Question 5: Why does Field Level Security sometimes not work?¶

Answer 5: Field Level Security (FLS) functions by registering triggers against specific events within Microsoft Dynamics GP. When these events occur (e.g., a window opens, a field becomes active), FLS executes its code to modify the user interface, such as hiding a field, disabling it, or applying a password. However, there are scenarios where FLS appears to be ineffective, leading administrators to believe it’s not working as intended. This usually happens because existing code within the window itself runs after FLS has made its changes, and that existing code then overrides or reverts the modifications applied by FLS.

This problem most commonly manifests with security modes like “Hide field,” “Disable field,” and “Lock field.” These modes are typically triggered when a window is initially opened. If the window’s native Dexterity or VBA code subsequently runs and includes logic to explicitly show, enable, or unlock the same field, it will override the FLS-applied changes. A frequent culprit for this behavior involves multicurrency fields. The multicurrency functionality is often implemented in a way that “originating” and “functional” currency fields overlap. Depending on the user’s view or system configuration, only one of these fields might be displayed at a time. If FLS is set to hide or disable one of these, but the multicurrency switching logic later enables it, the FLS setting will be negated.

In such situations where a user should be prevented from altering a field, FLS modes like “Password Before” or “Warning Before” are often more reliable than “Hide,” “Disable,” or “Lock.” These modes are triggered whenever the field becomes active, meaning they intervene at the point of interaction rather than relying on an initial state that can be overridden. When dealing with multicurrency fields, it might be necessary to apply a distinct Field Security ID to each individual multicurrency field to ensure comprehensive protection. Sometimes, for persistent field control, a more robust solution might involve using Modifier to physically move a field outside the visible area of a window, rather than solely relying on FLS, especially when encountering consistent override issues.

Let’s visualize a simple override scenario:

mermaid graph TD A[Window Opens] --> B{FLS Applies "Hide Field" to Field X}; B --> C[Field X is Hidden]; C --> D{Window's Native Code Runs}; D -- Contains logic to "Show Field X" --> E[Field X Becomes Visible]; E -- FLS appears not to work --> F[User Accesses Field X];

This diagram illustrates how a window’s native logic, running after FLS, can inadvertently or intentionally override the FLS settings, making the field visible or active again.

Question 6: How can I use Field Level Security to prevent saving a record in a maintenance window?¶

Answer 6: Preventing a record from being saved in a maintenance window using Field Level Security (FLS) can be a complex challenge due to the multiple ways a save operation can be initiated. There are typically seven distinct events that can lead to a record being saved in a standard maintenance window within Microsoft Dynamics GP. These include direct user interaction with the “Save” button, utilizing a lookup button that also triggers a save, or navigating through records using one of the four browse buttons (e.g., first, previous, next, last) and then subsequently closing the window. Each of these events can potentially trigger the underlying save mechanism.

If an administrator attempts to prevent saving by merely hiding the “Save” button using FLS, only one of these seven save events is addressed. The remaining six events would still function, often leading to the execution of a “Handle Changes” script. This script typically prompts the user with a system dialog box asking, “Do you want to Save, Discard or Cancel?” It’s crucial to understand that this prompt is a system dialog and not a Dexterity form. Although such dialogs can originate from Dexterity code, they cannot be directly addressed, triggered, or controlled by Dexterity itself, nor by Field Level Security, which is built upon Dexterity. This limitation means FLS cannot prevent or alter the behavior of these core system prompts.

Most maintenance windows in Microsoft Dynamics GP rely on either a Save_Record form-level procedure or a Save Record field script to perform the actual data persistence. Importantly, all the previously mentioned save events generally call the Save Record field script. For windows that utilize this specific field script, administrators can leverage Field Level Security to interject before the data is committed. By setting the Security Mode to the “Password After” option and associating a password ID, FLS can require a password authentication after the user attempts to save but before the data is actually written to the database. This provides a last line of defense.

However, for windows that primarily use a Save_Record form-level procedure for their saving mechanism, Field Level Security cannot effectively prevent the record from being saved through its standard modes. In such scenarios, alternative methods become necessary. These alternatives often involve custom modifications using Dexterity or Visual Basic for Applications (VBA) to introduce custom validation logic or override the default save procedures. Such customizations can provide more granular control over when and how data is saved, allowing for the implementation of complex business rules that FLS alone cannot enforce for critical save operations.

We hope this comprehensive FAQ guide has provided valuable insights into Advanced Security and Field Level Security within Microsoft Dynamics GP. Understanding these features is vital for maintaining a secure and compliant ERP environment.

Do you have further questions or specific scenarios you’d like to discuss regarding Dynamics GP security? Share your thoughts and experiences in the comments below!