Dynamics Biz Apps Blog

SELECT * from EntityView
ORDER BY ObjectTypeCode

NOTE: These are base system Object Types, due to custom entities this query can be run to account for missing ObjectTypeCodes from custom entities.

1 Account
2 Contact
3 Opportunity
4 Lead
5 Annotation
6 BusinessUnitMap
7 Owner
8 SystemUser
9 Team
10 BusinessUnit
11 PrincipalObjectAccess
12 RolePrivileges
13 SystemUserLicenses
14 SystemUserPrincipals
15 SystemUserRoles
16 AccountLeads
17 ContactInvoices
18 ContactQuotes
19 ContactOrders
20 ServiceContractContacts
21 ProductSalesLiterature
22 ContactLeads
23 TeamMembership
24 LeadCompetitors
25 OpportunityCompetitors
26 CompetitorSalesLiterature
27 LeadProduct
28 RoleTemplatePrivileges
29 Subscription
30 FilterTemplate
31 PrivilegeObjectTypeCodes
32 SalesProcessInstance
33 SubscriptionSyncInfo
35 SubscriptionTrackingDeletedObject
36 ClientUpdate
37 SubscriptionManuallyTrackedObject
40 TeamRoles
41 PrincipalEntityMap
42 SystemUserBusinessUnitEntityMap
43 PrincipalAttributeAccessMap
44 PrincipalObjectAttributeAccess
112 Incident
123 Competitor
126 DocumentIndex
127 KbArticle
129 Subject
132 BusinessUnitNewsArticle
135 ActivityParty
150 UserSettings
1001 ActivityAttachment
1002 Attachment
1003 InternalAddress
1004 CompetitorAddress
1006 CompetitorProduct
1010 Contract
1011 ContractDetail
1013 Discount
1016 KbArticleTemplate
1017 LeadAddress
1019 Organization
1021 OrganizationUI
1022 PriceLevel
1023 Privilege
1024 Product
1025 ProductAssociation
1026 ProductPriceLevel
1028 ProductSubstitute
1030 SystemForm
1031 UserForm
1036 Role
1037 RoleTemplate
1038 SalesLiterature
1039 SavedQuery
1043 StringMap
1055 UoM
1056 UoMSchedule
1070 SalesLiteratureItem
1071 CustomerAddress
1072 SubscriptionClients
1075 StatusMap
1080 DiscountType
1082 KbArticleComment
1083 OpportunityProduct
1084 Quote
1085 QuoteDetail
1086 UserFiscalCalendar
1088 SalesOrder
1089 SalesOrderDetail
1090 Invoice
1091 InvoiceDetail
1111 SavedQueryVisualization
1112 UserQueryVisualization
1113 RibbonTabToCommandMap
1115 RibbonContextGroup
1116 RibbonCommand
1117 RibbonRule
1120 RibbonCustomization
1130 RibbonDiff
1140 ReplicationBacklog
1200 FieldSecurityProfile
1201 FieldPermission
1202 SystemUserProfiles
1203 TeamProfiles
2000 UserFiscalCalendar
2001 UserFiscalCalendar
2002 UserFiscalCalendar
2003 UserFiscalCalendar
2004 UserFiscalCalendar
2010 Template
2011 ContractTemplate
2012 UnresolvedAddress
2013 Territory
2020 Queue
2027 License
2029 QueueItem
2500 UserEntityUISettings
2501 UserEntityInstanceData
3000 IntegrationStatus
3231 ConnectionRole
3232 ConnectionRoleAssociation
3233 ConnectionRoleObjectTypeCode
3234 Connection
4000 Equipment
4001 Service
4002 Resource
4003 Calendar
4004 CalendarRule
4005 ResourceGroup
4006 ResourceSpec
4007 ConstraintBasedGroup
4009 Site
4010 ResourceGroupExpansion
4011 InterProcessLock
4023 EmailHash
4101 DisplayStringMap
4102 DisplayString
4110 Notification
4200 ActivityPointer
4201 Appointment
4202 Email
4204 Fax
4206 IncidentResolution
4207 Letter
4208 OpportunityClose
4209 OrderClose
4210 PhoneCall
4211 QuoteClose
4212 Task
4214 ServiceAppointment
4215 Commitment
4230 UserQuery
4250 RecurrenceRule
4251 RecurringAppointmentMaster
4299 EmailSearch
4300 List
4301 ListMember
4400 Campaign
4401 CampaignResponse
4402 CampaignActivity
4403 CampaignItem
4404 CampaignActivityItem
4405 BulkOperationLog
4406 BulkOperation
4410 Import
4411 ImportMap
4412 ImportFile
4413 ImportData
4414 DuplicateRule
4415 DuplicateRecord
4416 DuplicateRuleCondition
4417 ColumnMapping
4418 PickListMapping
4419 LookUpMapping
4420 OwnerMapping
4423 ImportLog
4424 BulkDeleteOperation
4425 BulkDeleteFailure
4426 TransformationMapping
4427 TransformationParameterMapping
4428 ImportEntityMapping
4500 RelationshipRole
4501 RelationshipRoleMap
4502 CustomerRelationship
4503 CustomerOpportunityRole
4567 Audit
4600 EntityMap
4601 AttributeMap
4602 PluginType
4603 PluginTypeStatistic
4605 PluginAssembly
4606 SdkMessage
4607 SdkMessageFilter
4608 SdkMessageProcessingStep
4609 SdkMessageRequest
4610 SdkMessageResponse
4611 SdkMessageResponseField
4613 SdkMessagePair
4614 SdkMessageRequestField
4615 SdkMessageProcessingStepImage
4616 SdkMessageProcessingStepSecureConfig
4618 ServiceEndpoint
4700 AsyncOperation
4702 WorkflowWaitSubscription
4703 Workflow
4704 WorkflowDependency
4705 IsvConfig
4706 WorkflowLog
4707 ApplicationFile
4708 OrganizationStatistic
4709 SiteMap
4710 ProcessSession
4800 WebWizard
4802 WizardPage
4803 WizardAccessPrivilege
4810 TimeZoneDefinition
4811 TimeZoneRule
4812 TimeZoneLocalizedName
7100 Solution
7101 Publisher
7102 PublisherAddress
7103 SolutionComponent
7105 Dependency
7106 DependencyNode
7107 InvalidDependency
8000 Post
8001 PostRole
8002 PostRegarding
8003 PostFollow
8005 PostComment
8006 PostLike
9100 Report
9101 ReportEntity
9102 ReportCategory
9103 ReportVisibility
9104 ReportLink
9105 TransactionCurrency
9106 MailMergeTemplate
9107 ImportJob
9333 WebResource
9502 SharePointSite
9508 SharePointDocumentLocation
9600 Goal
9602 GoalRollupQuery
9603 Metric
9604 RollupField
10021 msdyn_PostAlbum
10022 msdyn_PostConfig
10023 msdyn_PostRuleConfig

Listed are the system Object Types, the query will also display Object Types for custom entities.

Sourced From: Pablo Peralta’s Blog

Share on Facebook

Posting publicly but still under edit, links provided are orginal sources.

You may or may not know the POA (principal object access) table is a table for sharing of records. Basically if you try to access a record that you do not own the system will check the POA and if the permission is there then you can access the record.

http://blogs.msdn.com/b/crminthefield/archive/2010/08/16/excessive-principalobjectaccess-poa-table-growth-in-crm-4-0.aspx
(START BLOG)
I often times work with customers that enter a large number of records inside their Microsoft CRM system. When reviewing their CRM table counts, they sometimes find that they have a larger than expected number of records in the PrincipalObjectAccess table (POA). The POA table is used to provide access to specific records for CRM users, and each record in the POA table represents one CRM object that is related to one CRM user. Records created in the POA table come from one of four ways:

• Share reassigned records with original owner: CRM System Settings

o If this is set to Yes, then records would be added to the POA table whenever an assign takes place. These records will have a value in the AccessRightsMask colum of the POA table.

• Direct sharing: Actions – Sharing

o When users explicitly share a record to another user, a record would be created in the POA table. These records will have a value in the AccessRightsMask colum of the POA table.

• Reparent Setting: Relationship Behavior

o Each entity has relationships with other entities (ex. Account to Case). By default, the Reparent option is set to Cascade All. With this setting, sub records would be shared to the owner of the parent record. For example: Let’s say that User1 owns Account1. User2 has access to Account1 and creates a case underneath Account1. With the out of the box Reparent options, a record would be created in the POA table that would give User1 access to the newly created case. These records will have a value in the InheritedAccessRightsMask colum of the POA table.

• Indirect Sharing

o When sharing occurs through a direct share, assignment, or parenting, if the relationship is set up to cascade the share to child records, additional records will be created in the POA table in order to give proper permissions to the new user for the relevant child records. These records will have a value in the InheritedAccessRightsMask colum of the POA table.
The Reparent setting is what seems to come as a surprise to some customers. Many customers will keep the Reparent setting set to Cascade All. This is a perfectly acceptable setting, but if the majority of your users already have access to the records that are being shared to them through their security role, the records in the POA table may not be providing much of a benefit.
It is possible to change the Reparent setting to Cascade None. In this scenario, records would not be auto-created in the POA table for the owner of the parent record. Building off of the example mentioned above: User1 owns Account1. User2 has access to Account1 and creates a case underneath Account1. With the relationship set to Cascade None, a record would not be created in the POA table for User1.
(END BLOG)

So, how do we determine the amount of sharing within the Pulse system. I have found an XML report for 2011 that will outline the sharing that is happening with the system.

http://sharingsummary2011.codeplex.com/

Also, I believe it would be good to run this script in order to see what types of Sharing is happening within the POA table, this may make the report not necessary but I feel that everything should be on the table.

select ObjectTypeCode, COUNT(ObjectTypeCode) as total
from PrincipalObjectAccess
group by ObjectTypeCode
order by total desc

SAMPLE RESULTS
ObjectTypeCode EntityName total
5 Annotation 3.166.458
4200 ActivityPointer 838.042
112 Incident 415.500
1 Account 38.087
4230 UserQuery 135
9100 Report 104
150 UserSettings 88
8 SystemUser 88
9106 MailMergeTemplate 20
2010 Template 3
4.458.525

More information on the POA table and understanding it, I have not fully explored this yet.

http://community.dynamics.com/product/crm/crmtechnical/b/crmcustomereffective/archive/2012/06/01/unmasking-crm-s-principalobjectaccess-table-with-a-free-secret-decoder-ring.aspx

So how do we manage the POA, here are some recommendations.

http://blogs.msdn.com/b/crminthefield/archive/2011/06/09/principalobjectaccess-performance-recommendations.aspx

(START BLOG)
One of the topics of discussion that can come up during the planning phase for a customers CRM implementation is Business Unit structure and sharing, which leads to the PrincipalObjectAccess (POA) table. As the POA table grows in size due to the sharing of records, which can be frequent in environments with a complex Business Unit structure, CRM performance can suffer. Below are some general recommendations that we provide to customers that are anticipating their deployment will have a complex Business Unit structure and/or frequent sharing of records.

• Share only what is needed

o By limiting the amount of sharing that takes place, we will reduce the total number of records in the POA table

o For more on sharing and the POA table see Jon’s post

 http://blogs.msdn.com/b/crminthefield/archive/2010/08/16/excessive-principalobjectaccess-poa-table-growth-in-crm-4-0.aspx

• Minimize the number of Business Units where possible

o Help reduce the need for sharing records

• Ensure users are placed in the appropriate Business Unit

o Can a user be moved further up the Business Unit hierarchy to give them the necessary access to records in another Business Unit

• Modify Security to allow users to see information outside of their Business Unit

o This will also reduce the need for sharing

• Once a record does not need to be shared any longer, stop sharing it

• Enable the EnableRetrieveMultipleOptimization registry key

o http://support.microsoft.com/kb/2535245

o Enabling this will cause the queries to make use of temp tables

 Evaluate splitting TempDB out to its own physically separate RAID array

• Ensure frequent queries that involve the POA table have appropriate indexes in place

Not all of these will be applicable to all deployments but the goal of most of these is to provide customers items to consider while they are planning out their Business Unit structure.
(END BLOG)

Share on Facebook