of the
We are all familiar with the record privileges in Dynamics CRM. User-owned entities have 5 access levels (None, User, Business Unit, Parent: Child Business Units, Organization) while organization-owned entities have only two of those (Go/No Go). Then there are miscellaneous privileges and training documentation states that (highlight is mine):
Each Security Role also includes miscellaneous privileges that relate to application features, such as Print, Merge, Export to Excel and Go Offline. These privileges have only two levels that represent an on or off setting because these privileges do not relate to records, they apply to features globally.
That’s where it gets interesting because some of the miscellaneous privileges can have more than two levels. It opens some additional opportunities to fine-tune security of your CRM implementation. For example, consider Send Email as Another User privilege
The level can be set to Business Unit, Parent: Child Business Unit or Organization (naturally, user always has ability to send as themselves). For example, managers can have ability to send on behalf of users in their Business Unit only while CTO can be allowed to pretend to be just about anybody in the system.
Other interesting privileges include ability to override product pricing on quotes, invoices, etc. For example, you can allow user to override product pricing of their quotes, but not anyone else’s.
The full list of miscellaneous privileges that can have multiple access levels:
| Tab in role editor | Roles with multiple access levels |
| Core | Publish Duplicate Detection Rules |
| Marketing | Configure Internet Marketing module |
| Use internet marketing module | |
| Sales | Override Invoice Pricing |
| Override Opportunity Pricing | |
| Override Order Pricing | |
| Override Quote Pricing | |
| Busines Management | Assign manager for a user |
| Reparent team | |
| Send Email as Another User | |
| Approve Email Addresses for Users or Queues | |
| Assign Territory to User | |
| Enable or Disable User | |
| Reparent user | |
| Customization | Activate Real-time Processes |
Only just noticed this tip. You are right, this paragraph of the training course is a slight over simplification. No training can (or should) attempt to document the entire application in detail, especially since this can change, and since the product team maintain accurate and up to date documentation such as found on MSDN, Technet, the Implementation Guide and SDK.
It would also makes exam preparation really hard for candidates if this level of detail were included, since anything mentioned in the training course is fair game for an exam question, so any kind of lists of exceptions or special cases are generally best avoided.
So, this description is a bit of a compromise, and your post does a great job of filling in some blanks.
It is true that there are miscellaneous privileges that relate to global *application* features such as the examples listed in the course, and that these type of *application* level privileges only have two levels applicable. Most of these are on the “core records” tab.
It is also true that there are other privileges such as those you list, which are listed under “Miscellaneous” section on other tabs, but most of these relate to another entity in some way. All of the sales ones are really special privileges for sales process entities, for example. Many of the others, while they feel like global features, really apply to users, teams, queues or processes, all of which are entities that can be owned by users, so these do support the 5 levels that relate to BU structures.
The distinction is subtle, and probably not interesting to users or even some admins.
(Aside: Internet marketing module has never been available outside the US, to my knowledge, and is a dead deprecated duck now, as far as I understand.)
I think the most unexpected one here is Publish Duplicate Detection rules. Since this is probably rarely granted to non-admin users anyway, it is quite a surprise that these rules have an owner, and that you can control who can then publish the rules, depending on their relationship to the owner. Since a published rule then applies to the system as a whole, this distinction of who owned it or published it seems a little strange, to me at least.