It would be great if as an admin I could login as another user in order to troubleshoot issues that arise. Instead of having to waste a license for my test user so I can change the test users security roles to mimmick that of the individual having issues.
This is an enhancement for CRM Online (and On-Premise), but there is no option for this in the Product Version drop-down list.
The enhancement request is for CRM Administrators/Developers to have the ability to view the entire CRM site as another user's role. Often times we are building out Security Roles, Business Units, Forms, etc. and need to ensure the end user is seeing, accessing, and function as intended for their work and role.
The enhancement would have a "View As" option for Admins/Developers and then and option to pick a Security Role (or a combination of Roles). Once these are selected, then a "Start Viewing" option to start the session. This will allow us to "play" that person's role, navigate, run reports, create Views, lookup records, etc. as the person. The limitation I would see is the ability to Create, Update, or Delete (CRUD) records. This should be left to the person needing to perform their tasks.
Is there a reason that Field Security cannot be enabled on out of the box fields? We have a number of clients with integrations with CRM to other backend systems and it would make more sense to enable this level of support. We may be able to work around this for the time being by using separate forms.
There is no OOB Security Role available for Team Member License
Require to give OOB Security Role to the User which do not provide the Security Roles mentioned in the Document of Team Member License in Appendix B: Plan 1 Applications
Require OOB Security Role for Team Member License
When we write solutions for ISVs (and occasionally for end users), there are often times when the native CRM privileges do not cover custom scenarios that apply. One common scenario is for managing role-based ribbon privileges (DisplayRules and EnableRules).
Instead of having to create a custom (secret) entity and use its native privileges to define ribbon rules on a per-role basis, it would be nice to be able to create privileges that can be packaged/deployed with solutions and able to be configured on roles. This would easily enable ISV-specific privileges and custom ribbon privileges that we could use with native ribbon rules, form script and custom code.
somtimes a user needs the permission to export data from only one entity. But you need to give him the permission "Export to Excel" and with this, it is possible to export the data from every entity. That is to much for some users.
Is there any way, to change the permission, so that we can give the users the permission to export only selected entities?
I am very pleased that Microsoft is introducing in CRM 2013 data encryption for sensitive system fields at rest. While that does an excellent job of securing Yammer tokens and email service passwords, it is a common occurrence among Dynamics CRM administrators to want to store other sensitive values that would benefit from at-rest encryption. I know that Adxstudio's portal product, for instance, stores user passwords, but I do not know how they handle securing those values. We've also had customers who require this level of security, for whom we have written custom encryption plugins to keep the at-rest data encrypted.
Now that data encryption is baked into the CRM product, it would be wonderful if there was a way to configure custom fields as "encrypted", ensuring that they, like the Yammer tokens and email passwords, are encrypted at-rest.
Field Security Profiles are a great addition to CRM 2011 and I am seeing increasing take up of this feature in a few deployments recently.
However, the feature falls short from an Administrative perspective.....
Right now, the Field Security profiles are individually assigned to a User record; which means that once a User has been created you have to go an maintain the User record individually to add a Field Security Profile.
Although you can go to the Field Security profile iteself a do a User 'Lookup' to add a few users, this falls short of being able to estalbish some kind of filtering/query to selct a group of users - E.g. Advanced Find like feature.
The option to attach a Field Security Profile does not even exist when you add 'Multiple new Users'.
For small deployments this is manageable; but when you have a deployment with 10's or even 100's of Users this is a considerable pain.
I would like to have the ability to attach the Field Security Profile(s) to a Security Role, so that when you assign a User with a Security Role, they get the relevant Field Security Profile(s). If there is an underlying design issue with this approach, then could I ask that the existing 'lookup' function (to add Users to the Profile) is replaced with Advanced Find like feature or even a mechanism similar to how Marketing List membership management works currently.
We noticed that after update to Turbo forms MS CRM started corrupt data on UI, by calling onChange handlers after onSave event of the form.
So, onChange triggered twice: first time (correctly) before save, and second time (incorrectly) after save. During second execution onChange validation depending on the logic could corrupt data on form, and these changes got automatically committed to database by auto-save.
Why this behavior should be fixed:
1) Additional run of onChange handler could not fix possible error caused by "malformed" GUID;
2) No validation should be run when form is already saved;
3) If "malformed" GUID is really severe issue user should be notified;
4) All changed after such silent verification should be confirmed by user;
4) CRM OrganizationData, .NET Guid.Parse does not have such restrictions in GUID format;
5) UUID standard has no requirement to have neither uppercase letter, nor braces;
Please check your customizations before upgrading to Turbo forms, it might be that you're affected by this bug. Your customers could lose they data because of this bug, and it would be hard to recover it if you have auditing enabled, and impossible to achieve if you haven't enabled it at all.