What are activity entites in MS CRM

Activities are tasks that you or your teams perform when they contact customers, for example, sending letters or making telephone calls. You can create activities for yourselves, can assign them to someone else, or can share them with other users or teams. An activity is any action which can be entered on a calendar and has time dimensions (start time, stop time, due date, and duration) that help determine when the action occurred or is to occur. 

As per business requirements we can create our own custom activity entity. And, we can create 1:N relationship with any other entities as just like normal entity.

Below are the list of features available for  activity entity.

1. It has default offline availability.
2. Mail merge is disabled for activity entity.
3. Activity entity ownership can be either team-owned or user-owned. You cannot set it as organization level.
4. You cannot display activity entity in sales, marketing or any other areas.
5. By default Feedback, Notes,  Connections and Queues are enabled by default we cannot change them.
6. Knowledge management cannot be enabled.
7. By default primary field for activity entity is subject which is a single line of text with 200 max length. We cannot change it.
8. A custom activity entity must not have relationships with activities.

Html encode or decode online

           

Actions on entity records

Each entity supports several records like create, update, delete or assign a record to team or user,. But not all actions are allowed on all entity or attributes. We need to verify IsValidForCreate, IsValidateForUpdate or IsValidateForDelete fileds values to check to know whether we can perform create, update or delete operations on that entity or attributes.

Below are the list of actions we do perform on entity records.

Create	To create a record in an entity
Update	To update an attribute or attributes of a records
Delete	To delete a record
Retrieve	To retrieve a record of an entity
RetrieveMultiple	To retrieve collection of records
Assign	Changes ownership of a record
Share	Grant, modifies or revoke access to a record
Associate	To create a link between a record and collection of records between related entities
Disassociate	To remove a link between a record and collection of records between related entities
SetState	To set the state of a record

Relationships between entities

We can build three types of relationships between entities.

1. One-to-many
2. Many-to-One
3. Many-to-many

I would like explain these relationships with an example. Assume there are two entities called A and B. As per the requirement A record can contains more than one B records, that means we need to create a one-to-many relationship between A and B, once you create the relationship, one A entity related lookup field will be created automatically in B entity. So, for each record you are creating in B entity you will selecting the respective A entity related record. One each record of A entity, you can see all the associated records of entity B in associated view.

Many-to-one is same as One-to-many if we are following above process from B to A.

The records for a many-to-many relationships are stored in an intersect entity which contains the ID of both the referenced and referencing records. In Many to many relationships we need to establish a link between records by associate or disassociate.

What is an entity in MS CRM

Entity in MS CRM used to manage business data. In simple terms we can refer entity as Table in database, and, each record in an entity can refer as a row in a table. And, each field in an entity can refer as a column in table.

There are three types of entities in MS CRM.

1. System
2. Business
3. Custom

As a developer, you will be dealing with Business and custom entities. System entites are purely internal usage of CRM. We cannot customize or delete system entites. Examples for system entities are workflows and asynchronous jobs etc.

Business entities are default entities CRM provide while installing. Examples for business entities are Contact, Account, Case etc.

Custom entities are entities which we will be create as per business requirement.. 

Teams in MS CRM

            Below are the some of the interesting points about Teams

1. While a team belongs to one business unit, it can include users from other business units.
2. You can use two types of teams:
• An owner team owns records and has security roles assigned to the team. The team’s privileges are defined by these security roles. In addition to privileges provided by the team, team members have the privileges defined by their individual security roles and by the roles from other teams in which they are members. A team has full access rights on the records that the team owns.
• An access team doesn’t own records and doesn’t have security roles assigned to the team. The team members have privileges defined by their individual security roles and by roles from the teams in which they are members. The records are shared with an access team and the team is granted access rights on the records, such as Read, Write, or Append.
3. If an owner team doesn’t own records and doesn’t have security roles assigned to the team, it can be converted to an access team. It is a one-way conversion. You can’t convert the access team back to the owner team. During conversion, all queues and mailboxes associated with the team are deleted. When you create a team in the Web application, you have to choose the team type Owner.
4. A system-managed access team is created for a specific record, other records can’t be shared with this team. You have to provide a team template that the system uses to create a team. In this template, you define the entity type and the access rights on the record that are granted to the team members when the team is created.
5. A team template is displayed on all record forms for the specified entity as a list. When you add the first user to the list, the actual access team for this record is created. You can add and remove members in the team by using this list. The team template applies to the records of the specified entity type and the related entities, according to the cascading rules. To give team members different access on the record, you can provide several team templates, each template specifying different access rights. For example, you can create a team template for the Account entity with the Read access right, which allows the team members to view the specified account. For another team that requires more access to the same account, you can create a team template with Read, Write, Share and other access rights. To be added to the team, a minimum access level a user must have on the entity specified in the template is Basic (User) Read.
6. Because of the parental relationship between the team template and system-managed access teams, when you delete a template, all teams associated with the template are deleted according to the cascading rules. If you change access rights for the team template, the changes are applied only to the new auto-created (system-managed) access teams. The existing teams are not affected.

7. The maximum number of team templates that you can create for an entity is specified in the MaxAutoCreatedAccessTeamsPerEntity deployment setting. The default value is 2. The maximum number of entities that you can enable for auto-created access teams is specified in the MaxEntitiesEnabledForAutoCreatedAccessTeams deployment setting. The default value is 5.. 

Business Unit in MS CRM

                 Below are the some of the points about Business unit

1. The organization (also known as the root business unit) is the top level of a Microsoft Dynamics 365 business unit hierarchy. Dynamics 365 automatically creates the organization when you install or provision Dynamics 365. You can’t change or delete the organization name.
2. You can’t change the name of a business unit or delete a business unit after it has been created. You can disable a business unit or change the parent, however. When you disable a business unit, all users and teams associated with the business unit are also disabled.
3. Changing the parent business removes security roles for users and teams associated with the business unit. You must reassign them.
4. You can change the business unit for an individual facility, equipment, or user. By changing the business unit for a user, you remove all security role assignments for the user. At least one security role must be assigned to the user in the new business unit.
5. You can delete a business unit to completely remove it from Microsoft Dynamics 365.

                 Before deleting a business unit, be sure to consider the following:

• Deleting a business unit is irreversible.
• The records owned by the business unit are deleted at the same time you delete the business unit.
• You can’t delete a business unit until you delete any associated users, teams, and child business units.

6. You can assign a different parent business to a business unit to accommodate changes in your business requirements. When you reassign a business unit, any child business units are also reassigned with it.
7. By default, when you create a user the user has read and write access to any data for which they have permission. Also, by default, the user client access license (CAL) is set to Professional.

                 Access mode. This setting determines the level of access for each user.

• Read-Write access. By default, users have Read-Write access that allows them access to data for which they have appropriate permission set by security roles.
• Administrative access. Allows access to areas that the user has appropriate permission set by security roles but doesn’t allow the user to view or access business data typically found in the Sales, Service, and Marketing areas, such as accounts, contacts, leads, opportunities, campaigns, and cases. For example, Administrative access can be used to create Dynamics 365 administrators who can have access to perform a complete variety of administrative tasks, such as create business units, create users, set duplicate detection, but cannot view or access any business data. Notice that users who are assigned this access mode do not consume a CAL.
• Read access. Allows access to areas for which the user has appropriate access set by security role but the user with Read access can only view data and can’t create or change existing data. For example, a user with the system administrator security role who has read access can view business units, users, and teams but can’t create or modify those records.