Custom Views for Case Records in Dynamics 365 - dynamics-crm

I have a Case View which shows all the records that were created by the me (My Cases view). I now want to all those Cases edited/modified by me to be visible in that view. The problem is those modified by me could be later modified by the system when a workflow updates the Case, which changes the Modified By User data. Thus, not allowing me to use Modified By (Current User) as a condition for the view.
Is there any other way or condition which I can use to make sure the I can accomplish this?
Thank you in advance.

You may create a new Entity with One to Many relationship with Case Entity. Whenever there is Insert or Update you can add a new record in the mapping entity with Modified By Information and Created On OOB.
You can create a view in the new entity with record modified by Me.
P.S - Single case record will be edited multiple times with multiple users so it will result in high volume of data and may want to look for archiving strategy.

Related

Model-driven PowerApp: Best practice to display subgrid of records with no appropriate primary column name

Background
Each Dataverse table contains a primary name column. When displayed in a subgrid, clicking on the primary name column will navigate to the form so that the user can edit that row. Most subgrids in my application work this way.
The Problem
I have a Course form with a list of participants displayed in a subgrid. The subgrid displays each student's name (as a link) and the grade received in the course. There is no appropriate primary name column for this Participant table. To edit the participant record, the user must select the row in the subgrid, then click the subgrid's Edit button. As a result, this UI is different from all other subgrids in the application and I know that user's will click the student name to try to edit the participant record and be confused when they are presented with the student record.
Am I missing something? Is there a better way to handle this?
It's a common problem I face quite often. Here is usually what I would do.
Make sure the Primary Name Column always contains relevant information to the user to be able to quickly identify a record. Sometimes it requires copying information from one or multiple other columns into the primary column.
In your case that would probably means concatenating the student's name and grade.
How to do that?
Common to all solutions below
Use one of the following solution to copy the content of one or several fields into the primary column.
Make sure the solution you select also updates the content of the primary name column when one of the copied field is updated.
Remove or hide the primary column from the form, the name of the record will be displayed at the top of the form anyway and you probably don't want users to play with it.
Display the primary name column in every subgrid.
I would recommend not adding the fields copied into the primary column in the subgrids to avoid confusion.
Solution 1 - Classic Workflow
Create a classic workflow that runs when a record is created / updated
Pros:
Very quick to put in place
Runs synchronously (users will see the name updated in real-time)
Cons:
Not very practical if you need to add business logic (using different fields as source depending on a certain condition for example)
Solution 2 - Power Automate
Create a Flow that runs when a record is created / updated
Pros:
You can implement complex business logic in your Flow
Cons:
Runs asynchronously (users will have to refresh the page after the creation of a record to see the record's name)
According to Power Automate licensing that flow would certainly be considered as an "enterprise flow" and you are supposed to pay 100$ / month. That specific point must be taken with a grain of salt. I had several discussions with Microsoft about it and they haven't given me a clear answer about what would be considered an enterprise flow.
Solution 3 - Plugin
Create a plugin that executes when a record is created / updated
Pros:
You can implement very complex business logic in your Flow
It can run synchronously
Cons:
Pro-code (I put it as a con since Model-Driven App is a low-code / no-code approach but there is nothing wrong about pro-code per say)
Developing a new plugin for each entity where you need this logic is kind of overkill in my opinion. I would consider developing something very generic that would only require some sort of configuration when the logic needs to be applied to a new table.

Adding multiple entities to one main form

I am in the process of modifying forms to account for V9 of Dynamics which is being rolled out currently.
Our environment is using Dialogs but these are being deprecated with V9 which means we have to prepare the forms to be used instead of these Dialogs.
Due to how fragmented our solution is the data is all over the place in different entities and can all be written too at different times.
Is it possible to have multiple entities/records on the same form which are all editable? This way I can run rules to hide and show as people edit specific fields.
From what I can identify, there is no "true" way to achieve this. However, if there are entities which are linked via a relationship within the solution, it is possible to add the "Party List" type field to the form and this will act as the link between the two entities. When you go to search for an existing record within the related entity, there is a new button which allows you too create a new record of that entity which directly associated with the form you were working on initially.
We do have editable subgrids. Add the subgrids of related entities & allow users to edit the related records in main record form at one shot.

Autonumbering in new entity

I have an custom entity which needs to have a case number for an XRM Application, can I generate a case number from the Service -> Case.
If this is not possible, how can I do this with a plugin, I've looked at the crmnumbering.codeplex.com but this doesn't support 2011, anybody outthere have a solution or should I rewrite it myself?
thanks
I've ran into this same type of issue (I need a custom # for an entity). Here's how you can do it:
Create an Entity called "Counter"
Add a field called "new_customnumber", make it a string or a number depending on what you want
Create a new record for that entity with whatever you want in the new_customnumber field (let's say "10000")
Create a plugin (EntityNumberGenerator) that goes out and grabs that record (you'll probably want to set the security on this record/entity really tight so no one can mess with the numbers)
On Create of the "custom entity" fire the plugin. Grab the value in new_customnumber save it to the "custom entity" (let's say in a "case" field) increment the new_customnumber and save it to the Counter entity.
Warning, I'm not sure how this is with concurrency. Meaning I'm not sure if 2 custom entities being created at the same time can grab the same number (I haven't ran into an issue yet). I haven't figured out a way to "lock" a field I've retrieved in a plugin (I'm not sure it's possible).
You will be unable to create a custom number for custom entities from the normal area you set a case number.
Look at the CRM2011sdk\sdk\samplecode\cs\plug-ins\accountnumberplugin.cs plugin. It's really similar to what you want.
Ry
I haven't seen one for 2011 yet. Probably easiest to write it yourself.
I've always created a database with a table with a single column which is an IDENTITY column. Write an SP to insert, save the IDENTITY value to a variable, and DELETE the row all within a transaction. Return the variable. Makes for a quick and easy plug-in and this takes care of any concurrency issues.
The performance is fast and the impact to your SQL server is minimal.

MS CRM 4 - Custom entity with "regardingobjectid" functionality

I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.

MS CRM Save + Copy as new (Custom Entity)

I have a custom entity in Microsoft CRM (4.0). The user has to input records however usually they have a batch of 20+ records that are almost the same apart from 2 or 3 fields which need changing. I know I need to write some custom code to enable this functionally. However can anyone recommend any methods to do this.
Ideally there should be a button that will save and create a copy as a new entity.
My Current way of thinking is to pass all the details as part of the URL and use javascript to strip them out on the page load event. Any ideas welcome.
Thanks
Luke
I found the answer here:
http://mscrm4ever.blogspot.com/2008/06/cloning-entity-using-javascript.html
I've used it and it appears to work well.
Since there are numerous fields, but only certain fields values are different, then i am thinking to set the default value to all the fields, so that users just need to alter those values when needed.
In my approach, i will hook a javascript function on load of the form data entry screen and use XmlHttp approach/Ajax approach to hook to the custom web service to pull/retrieve the default values of each fields. Or you can set those values at the javascript function itself, but the drawback of this, it's difficult to customize later. So i will choose the approach to hook to the custom web service and retrieve those value from some application parameter entity.
Your idea of providing a "clone" button is also a great idea, which means that it will duplicate all the attributes of the previous record, into a new record, so that it will save time for data entry person to customize the different value
EDIT
Since you would enter records in batch mode, how about customizing .ASPX screen to enter records. By customizing through .ASPX screen, you can use a tab , so that users can browse through tabs, to customize the value/attribute of each record.
There will be a "save" button as well as "clone" button to clone some common attribute or value.
I would create a custom web service that would accept the entity type and the ID of the record I'm cloning. Your "Save and Clone" button would call the service, and the service would handle the details of retrieving the current record and deciding which fields to set on the new record. The service creates the record, and sends the Guid of the record back to your button, which then opens up the newly created record.
This way, you avoid the messiness of setting/getting values in JavaScript and tying which fields to set/retrieve directly to your OnLoads, as well as avoiding the possibility of query string that's too long.
The service could easily be sufficiently generalized so that all you'd have to do is add your button to any entity, and it would work, assuming you'd set up your service to handle that particular entity.
One possible downside is that since the clone record button would actually create the record, the user would be forced to delete the cloned record if they decided they didn't want to clone the record after all.

Resources