There are a quite a number of nuances to know when developing for entities with access teams. If you are developing an integration or migration package to an entity with access teams, there are a few important things to note, and this blog will explain some tips and strategies for updating access team records through web services and also provides some technical considerations when using access teams.
Table Locking
When creating an access team, CRM will put update locks on system user principals and team membership. Considering this, you will want to be mindful in how you distribute your work when multi-threading (see Optimizing SSIS with Microsoft Dynamics CRM). Because these locks are based on the access team’s system user, you want to maximize performance by distributing based on system user, rather than load balancing.
Doing this will prevent deadlocking between the different tasks, which would be a significant problem when using load balance distribution.
Performance Issues
Keep in mind that creating access teams takes time. When inserting or updating in bulk, you will definitely notice a slowdown when you’re doing this process. Because of the update locks that are enforced when creating an access team, you will only be able to modify one record at a time per system user. If the user has over one hundred thousand records to process, this will take anywhere from a few hours to multiple days to complete.
The speed of processing a large amount of records will vary drastically depending how many system users you are importing for and how many records they each have.
For example, if you have one million records to create, the process will go much faster if you make the queue for a thousand system users each with a thousand records, rather than for a single user with one million records to create, which would most likely take days.
A Few Things to Consider
If you are considering using access teams, here are a few technical considerations that should be considered:
1. It’s difficult to make bulk changes to large quantities of records.
- If your CRM has millions of accounts and you are going to implement access teams for thousands of users, then access teams probably aren’t for you. This is especially true if you foresee having to make bulk updates across access teams.
2. Access Teams are best for security.
- People will often want to use access teams because they like the idea of only seeing their assigned accounts when signing onto CRM. If you want this for any other reason than security (for example, if other system users shouldn’t be seeing other system users’ accounts), consider another solution such as using Connections or creating a custom entity.
Access teams work great for providing security and managing smaller records, but there are some technical considerations before you implement them. Be sure to weigh the convenience of access teams with the effort to update them with data integrations/migrations, and be prepared to organize your record update so that it is as efficient as possible.
Happy CRM’ing!