POA analyzer
The PrincipalObjectAccess (POA) table stores information about record sharing in Dataverse-based CRM systems such as Microsoft Dynamics 365 Field Service. The POA analyzer tool in Resco Mobile CRM inspects the POA table and identifies anomalies that might result in slow synchronization or server timeouts. It downloads the table content and computes various aggregates, especially the number of shares per entity and user.
Prerequisites
- Resco Mobile CRM version 18.0 or later
- Power Platform, Dynamics 365 Field Service, Dynamics 365 Sales
- App user must have read access to the POA table.
User experience
- Start Resco Mobile CRM.
- Go to the Setup/Settings page.
- On the Advanced card, tap POA analyzer.
- Tap Start and wait until the analysis is complete.
While processing, the analyzer displays progress messages and occasionally also intermediate results. You can tap Abort to stop. After the analysis is over (even if aborted), the final summary is shown in a text window (Desktop) or as an email (mobile devices, WinRT). Be patient. The analysis takes time: around 0.15 ms/rec. For example, analyzing a POA table with 10M entries might take ~25 minutes. The size of POA table is not known in advance, hence it is not possible to estimate the duration of the analysis.
What is POA?
POA refers to the Principal Object Access table. Every POA row designates a CRM record shared with a principal (user or team) and the permissions to that record.
Key columns in the POA table:
- PrincipalId: ID of the user or team being granted access.
- ObjectId: ID of the record being shared.
- ObjectTypeCode: Numerical code representing the entity type of the shared record. (https://msdynamicscrmblog.wordpress.com/2013/07/18/entity-type-codes-in-dynamics-crm-2011/)
- AccessRightsMask: Granted access (e.g., Read, Write, Assign).
POA records are created when a user explicitly shares a record with another user or team. Due to sharing's cascading behavior, the above explicit share is typically accompanied by (implicit) sharing of related records. For example, the sharing of an account record normally implies the sharing of related contacts (and other related records).
Performance considerations
Before accessing any CRM record, Dataverse executes a permission check on that record. First, permissions assigned via role-based security are checked. If the user has insufficient rights, Dataverse checks the POA table for permissions to that record.
A large number of entries in the POA table can affect server performance. When the server is under pressure, this may affect Resco Mobile CRM when syncing or in the online mode.
Best practices for POA table:
- Keep the POA table as small as possible. Organizations report performance degradation when the table grows beyond 20M records.
- Prefer sharing with teams instead of individual users.
- Review cascading rules for sharing.
- Automate POA cleanup (such as cleaning shares older-than-x-days or orphaned shares)
- Relax security rules by allowing organization-wide visibility where appropriate. (This can be done for some child entities, option sets, etc.)
Sample output
(Full POA table analyzed)
35946 users, 96585 teams
6811755 shared, processing took 981969ms
Entities with 1000+ shares:
customer_importviewmessage -> 5624680
annotation -> 751596
userquery -> 67616
msdyn_analysisresult -> 50222
connection -> 49232
usersettings -> 36088
systemuser -> 36088
customer_contactdetail -> 28208
customer_workexperience -> 26287
customer_individual -> 21573
customer_education -> 21561
customer_address -> 21496
customer_photo -> 20035
conversationtranscript -> 17154
userqueryvisualization -> 6314
customer_registrationgroup -> 5787
customer_cpcaseshare -> 4801
customer_specificneed -> 4116
userform -> 3665
customer_referral -> 2873
activitypointer -> 1526
customer_entitlementcard -> 1518
botcomponent -> 1327
customer_sgbvcase -> 1002
Teams/Users with most shares:
(USER) John Smith -> 3100897
(USER) Jane Carpenter -> 1039817
(USER) Bob Thatcher -> 508402
(USER) Rebecca Cook -> 368849
(USER) Pierre Potter -> 182834
(TEAM) Printing Operator - USA - AA -> 142163
(USER) Don Mason -> 118529
(USER) Mike Fisher -> 114989
(USER) James Sawyer -> 89277
(TEAM) ABC Gang - USA - AA -> 63637
(USER) Ann Farmer -> 57425
(TEAM) ABC Federation - Related Individual Access Team - USA - BB -> 50942
(TEAM) ABC Team – BB - Related Individual Access Team - USA - BB -> 47711
(TEAM) Printing Operator - USA - DD -> 43109
(TEAM) ABC Union - USA - AA -> 38751
(USER) Samuel Cartwright -> 37528
(TEAM) Printing Operator - USA - CC -> 35941
(USER) devops-dynamics -> 32400
(TEAM) Printing Operator - USA - Cc -> 24954
(TEAM) ABC Group - Related Individual Access Team - USA - BB -> 24595
Synced entities with shares:
annotation -> 751596 shares
connection -> 49232 shares
systemuser -> 36088 shares
customer_contactdetail -> 28208 shares
customer_workexperience -> 26287 shares
customer_individual -> 21573 shares
customer_education -> 21561 shares
customer_address -> 21496 shares
customer_photo -> 20035 shares
customer_registrationgroup -> 5787 shares
customer_specificneed -> 4116 shares
customer_referral -> 2873 shares
customer_entitlementcard -> 1518 shares
customer_relative -> 604 shares
customer_skill -> 359 shares
customer_verification -> 153 shares
customer_counselling -> 82 shares
customer_document -> 58 shares
customer_inconsistency4 -> 10 shares
customer_counsellingnew -> 5 shares
customer_reception -> 2 shares
customer_socioeconomicscore -> 1 shares
customer_assistancerecord -> 1 shares
Synced entities with no shares:
attributemap
businessunit
connectionrole
connectionroleobjecttypecode
entitymap
customer_affiliation
customer_alias
customer_assistancedeliverytype
customer_assistancelocation
customer_assistancemeasurement
customer_assistancesector
customer_assistancetype
customer_biometricidentity
customer_biometricprovider
customer_comment
customer_communicationsubcategory
customer_connectionroleinformation
customer_correctiveaction
customer_country
customer_departureformalities
customer_departureformalityorganization
customer_documentcategory
customer_documentsubtype
customer_documenttype
customer_educationdegree
customer_educationlevel
customer_educationstatus
customer_entitlementcardsubtype
customer_entitlementcardtype
customer_ethnicity
customer_eventtracking
customer_exitentrypoint
customer_fieldcatalog
customer_householdincome
customer_incometype
customer_individualproperty
customer_language
customer_languagecode
customer_legalstatuschange
customer_legalstatuschangereasoncode
customer_localconfigurationsetting
customer_locationlevel
customer_mobilereportbulink
customer_nationality
customer_occupation
customer_owningoffice
customer_partner
customer_primafacieinformation
customer_processdetailcode
customer_propertycondition
customer_propertyownership
customer_propertytype
customer_rapidmobilereport
customer_rapidusersyncfilter
customer_rapidusersyncfilterlink
customer_rappdownload
customer_rappuiconfiguration
customer_receptionspecificneed
customer_registrationgrouplink
customer_religion
customer_representative
customer_serviceprovider
customer_servicesubtype
customer_servicetype
customer_sharinginformation
customer_signature
customer_socioeconomicprofile
customer_socioeconomicscoretype
customer_sourceofreferralcode
customer_specificneedcode
customer_specificneeddetailscode
customer_template
customer_translation
customer_v3event
customer_v3results
customer_verificationstatuscode
relationshiprole
resco_chattopic
resco_chatuser
resco_favorite
resco_mobilereport
resco_usersettings
team
transactioncurrency
Analysis
The server POA table has 6.8M records - a considerable amount, but not a huge number.
Frequently shared entities:
- progres_importviewmessage - 82% of all shares
- annotation - 11% of all shares
Some users seem to have too many shares:
- John Smith has 45% of all shares
- 7 other users have over 100K shares
- These eight users are responsible for 82% of all shares. (Note there are 36K users.)
From the point of view of the Resco app, the only strange thing is the large number of annotation shares.