Month: December 2021

Queues in Case Management: Part 1

Customer service management may require different type of attentions and monitoring depending on parameters such as the different types of customer, priority, different products or services, different subscription levels (regular, premium customers), various activity categories, different geography etc.

Defining Queues is helpful to organize, monitor and prioritize the work by having a centralized list of pending work that needs attention and sorting tasks by type or by the people assigned to complete them

A queue is created by default for each and every user in D365 customer service, we can define additional queues based on our requirements as mentioned above. Let us define a queue and check further details. we have to define paramers for the queue

  • Name: Name of the queue
  • Type – Private or Public : Private queue is having access to limited members and we have to add the members to it. Where as public queues are accessible at organization level
  • Incoming email address : All the messages sent to queue are send to this email Id
  • We can select which emails can be converted to activities

Once we create the queue, the mailbox is auto created.

Few important things to be noted for queue based on my experience

  • Queues are not included in solution, hence deployment can not be done with solution deployment. We did recreate the queues manually. There might be better ways to do it, I am yet to check
  • Once the queue is enabled for any entity, it can not be disabled
  • The items added to the queue are called as Queue items
  • Any queue item, which is actually a record , can be added to only one at any point of time
  • When two agents simultaneously add cases to the queue, then the system creates two queue items instead of a single queue item
  • If we have created workflows or used custom API to assign cases to agents and if a same case is assigned to two agents at the same time, then the system creates two queue items instead of a single queue item
  • From a queue, when an agent picks a case created by another agent and releases it, then the case gets assigned to the queue owner and not the agent who created the case
  • If we have to delete any queue, it must be removed from routing rules and shall contain no queue items, otherwise queue can not be deleted
  • When user releases or picks up the queue item, there is option to remove the item in queue or retain. By default it is retained. If we chose Yes to remove, the item will be removed from the queue
  • Actual entity record and queue item are different, when we remove any item from queue, record will not be deleted

Creating queues in below easy steps

Go to Settings- Service Management- Queues

Enter all the details based on the requirement as explained above, with various options.

Once the queue is saved and Queue items are associated with th
Queue Type is one of the important attribute
which emails should be converted to activities is defined based on this attribute

Once the queue is created, we can define the rule(s) to auto assign the items to the queue as shown below

In the rule we can define the filter criteria, which is similar to advanced find to match the records and if the record matches that criteria, it would be routed to the selected queue or user or team. Here we are discussing about queue, hence queue created in above step is selected

We have seen how to create queues and routing rules in this post Let us see continue to understand how to use the queues and how the routing rules work in next post

Entity Ownership in D365 CE

When it comes to Ownership of the entities and records, there are lot of scenarios.

What is the relation between the entity ownership and the actual record owner? Would the records be accessible to all users or a set of users. How can I restrict some users from accessing data from the entities? What happens if I share the record with someone? How ownership affects the related entities/records? What is Access team vs Owner Team? when to use which type of team? See these are so many questions, let us try to find answers to these questions

Let us go by the definition – The type of ownership defines some of the operations that can be performed on a record.  Ownership for an entity is defined in the metadata property OwnershipType. Here are the four types of Owneship types used in D365. You can refer to Microsoft Docs for more information

Ownership TypeDescription
Organization OwnedContains data involving something that belongs to or that can be viewed by the whole organization. Organization-owned entities cannot be assigned or shared. For example, products are owned by the organization. These entities have an attribute named organizationid.
Business OwnedEntities that belong to a business unit. These entities have an attribute named owningbusinessunit.
User or Team OwnedAssigned to a user or to a team. These entities contain data that relates to customers, such as accounts or contacts. Security can be defined according to the business unit for the user or team. These entities have attributes named owningteam and owninguser.
NoneThese entities are not owned by another entity.

Let us understand the fact that None and Business Unit type of Ownership is available for any custom entities. There are some out of box entities which have these ownership types such as Attachments or Business Unit entities

Attachment has None Ownership
Business Unit has Business Unit Ownership

When we create custom entities we can chose either “User or team” or “Organization”. We get the same options in both, our classic Dynamics solution and Data verse where Entity is called as table.

When we have above options to chose as Ownershiptype, the entity can be either owned by a user, team or organization. If we want everyone in the organization should have access to the entity records, then we should chose the ownertype as organization. For Organization owned entities, the two types of security access levels as Global and None. Oranisation owned entity records can not be shared or assigned.

If we want to restrict the access to the entity records to authorized users, then we should select the user or team as owner type. In case we need to expand the access, we can share the entity record with other teams or users. The record even can be assigned to another team or user. When we look at the security roles for user or team owned entities, we can go to five access levels such as : Global, Deep, Local, Basic, and None.

As we have understood user or team owned entities are more restricted than the organization owned ones. Hence when requirements are not clear then to be on the safer side, make the entity as user or team owned instead of organization. We can not change the ownership once the entity is created.

In this post we have seen how to define the ownership of the entity and what is impact of it. Let us see how records sharing and assigning works in next post.