Creating a new security role in Microsoft Dynamics CRM (Best Practices)

It is helpful to create new security roles in Microsoft Dynamics CRM to control access for users. For example, you want a user to have the ability only to see records that they own, or perhaps you do not want your users to be able to delete any existing CRM records -- creating a new security role can provide these restrictions.

To create a new security role in CRM, navigate to the Settings tab >> Administration >> Security Roles. There is a default baked-in set of standard security roles provided by Microsoft. If you open one of these up you will notice that you can not edit these. In order to create a new security role there are two ways to do so:

1. Click the New button at the top of the list.
2. Copy an existing security role, rename, and modify to your liking.

It is a best practice to go the route of Option 2 as it is far easier to whittle away the permissions you do not want the role to have than to build a role from scratch. (Unless you have experienced the thrill of banging your head against the wall whilst creating a new security role from scratch, it may not be outwardly obvious that this can lead to the fool's task of an Easter-egg hunt for assigning necessary permissions.) An exception where you may want to create a New security role from scratch is if the role will only contain a few "add-on" permissions (take the example above where the majority of your users will not be able to delete records, however you want to create a simple role where the delete privilege is allowed for say Accounts and Contacts).

This leads into the concept offered by Microsoft called "layering". A user can be assigned multiple security roles giving that user as much access as the highest level of security they are assigned to. If we refer to my examples up top, if a user is assigned to the role that does not permit them to delete any existing CRM records but also to the new role you created that allows them to delete Accounts and Contacts, they will be able to delete Accounts and Contacts despite being assigned both roles.

Management Reporter does not display GL account descriptions

The problem report was built with a row set listing the full range of main accounts (+Main = [????], for ease of maintenance), and a column set which included DESC and ACCT columns. Drilling down on the main report page for the account list displayed the account string and correct period amounts, but some of the account descriptions were missing.

The same report run for the prior month displayed all of the account descriptions.

Drilling down on various individual accounts revealed that those not showing descriptions each had only unposted transactions in the current month (for comparison, accounts with both posted and unposted transactions had their descriptions displayed)

When the open batches were posted, the report displayed all of the account descriptions.

A Window is Not Visible: How to Move Off-Screen Windows Back into View

Every once-in-a-while we receive a call from a client who launched an application, but the application didn't show up on their screen. They confirmed in the taskbar that the application was running. However, the window was not visible on their screen.

If you use a secondary monitor, and/or if you operate within a remote desktop environment, you may have experienced this issue. When a secondary monitor is disconnected, or the display settings are altered, sometimes applications will still operate as if nothing had changed with the monitor or display. The window opens in an "imaginary" place off to the side, where that monitor used to be.

Here are simple steps to move an off-screen window back to your screen:

1. Make sure the application is selected (choose it in the taskbar, or use the ALT-TAB keys to select it).

2. Type and hold down ALT-SPACE, then type M. (IMPORTANT NOTE: If you're working on a remote desktop or cloud, use ALT-DELETE instead if ALT-SPACE.)

3. Your mouse pointer will change to have 4 arrows.

4. Use the arrow keys on your keyboard to move the window back onto your screen.

Some tips to avoid this happening in the first place:
-- Move open windows to your primary monitor before disconnecting the secondary monitor.
-- If shutting down, do so before disconnecting the secondary monitor.
-- When working in a remote desktop, do not disconnect from the remote desktop using the "X" key at the top. Instead, close all open applications, and then go to the Start menu and select "Log Out". (This is a good practice in general, as failure to log out of a remote session could cause several other problems.)

Management Reporter 2012 error when you sign in to a company: “The connection to the Microsoft Dynamics GP database failed"

We had a recent error message come up when attempting to set the default company within management reporter. The message stated the following:

"Microsoft Management Reporter 2012 error when you sign in to a company: “The connection to the Microsoft Dynamics GP database failed.”

The sa user was still able to access the companies, yet any other GP user was not. Access rights were confirmed for both the GP users and domain users within Management Reporter.

In researching this error the following cause was discovered:

The server name that is listed in the ODBC on the client computer that connects to GP has a different name for the SQL Server in it versus what is listed in the Company Settings in Management Reporter.

The following link provides instructions on how to correct this situation. Once we performed these steps all the users previously setup in Management Reporter were able to access their companies.

Dynamics GP transaction will not post

One of our clients called for assistance with a receivables batch which refused to post. GP did not return any error messages, and the user had sufficient permissions to post this batch. The DYNSA user was able to post this batch in the test company, but not in the live company. When posting was attempted GP briefly displayed the posting status window and returned to the batch entry window without making any changes.

No errors were found in the dex_sql log or a SQL trace.... but there was a lock on the PM10000 table held by another user. Once this user logged out of GP, the DEX_LOCK table cleared and the batch posted successfully.

You can use the following SQL command to view the list of active GP users, and any locks held at the time you run this query:

, L.session_id
, L.row_id
, L.table_path_name
ON A.SQLSESID = L.session_id

Try having any users with a lock close all windows, and if the lock persists, have them log out of GP.

Syndicate content