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.
Related
I'm new to CRM, and am having difficulties implementing a subgrid onto an account form. I am not a programmer.
I will not bore you with the methods that I have tried to so far; that could take a while. Suffice it to say, I am having no luck.
i have created and imported two sets of records from my SQL database. One set was imported into the standard Accounts entity and the other was imported into a custom entity; let's just call that it Problems.
The relationship between Accounts to Problems is one-to-many. Each Account has a "problemID" and each related Problem has a "problemID" as well.
I need to be able to place a subgrid containing all related Problems onto the Accounts forms. I need to be able to see the old ones and create new ones.
How would YOU handle this?
Many thanks!
For a 1:N relationship between Accounts and Problems you only need a lookup to the Account Entity on the Problem entity. Then you can:
Edit the Account Form
Insert a Sub-grid
Set the sub-grid to look to "Only Related Records" for "Problems"
I want to modify the view of 'Activity' entity, opened the view and try searching for edit filter criteria option and it's not available on view form.
please see below
Can you please help to advice me on how I can add filter criteria for this view above. Or how to make it visible the option 'Edit filter criteria' on the form of a view.
Any suggestion will be much appreciated. Welcome for any feedback...
I don't know any way to do that, but you can do your custom views and for example change the default view for that entity. With custom view you can change everything.
See here step by step: http://www.powerobjects.com/blog/2008/08/11/creating-and-editing-views/
What you want is impossible to achieve. Pedro's suggestion is your only option. Create your own Activity view, and then you can create your own filters. You definitely cannot create your own Associated Views. Public Views are the only ones you will have a hope of creating or modifying, and in this particular case, you are still restricted.
There are various places spread throughout CRM where you will run into problems like this, where an entity, view, or field is "locked down". This is the cost of starting with platforms like CRM which are a blackbox that only offer customization up to a certain point.
The problem in this specific case has to do with the nature of activities and the various activity types. Under the hood, there really is not a traditional record type for Activities. The Activity entity is really a "pointer entity" (note the internal name "activitypointer"). Activities really point to other entity types (in this case Activity Types) such as Email activities. The Email entity is more of a traditional entity which you can run standard queries against--but even still that is "locked down".
This additional layer of complexity makes dealing with Activities programmatically more difficult (ex. querying the data, modifying the data via a plugin/SQL, etc.) and, in this particular case, makes even the most basic customizations impossible.
I have quite a complex class that has three one-to-many relationships and two many-to-many relationships with other classes. What I would like to do is to enable the user to fill all the details one by one - in one step or even better in multiple steps (wizard).
My class is called PeriodicTask - user has to select one Server object (which represents SQL Server instance ) and depending on the selection I need to present the user with the ability to select which databases he wants to use ( the best option would be to use checkboxes). I don't really know how to achieve this.
I would start with creating an action that returns JSON with databases for the selected server. It'll be invoked by jQuery. So far so good, but what to do then?
Should I add <input type="checkbox"> to the form for every database or maybe create another form and post to some other action? How to parse that when the form is submitted? Can I split it somehow into smaller steps ? HTTP is stateless so I somehow need to pass or remember the data that was previously submitted - how?
PS> I'm using Entity Framework here, so part of the class hierarchy is as follows:
You could do it like this:
User selects server instance from
dropdownlist.
After selection dropdownlist fires "change "event, handler of
which loads databases list to form using ajax (your action can provide JSON or html with checkboxes)
User selects checkboxes and presses
submit button
On submit you collect
checked item and post to action
using javascript
I would look at creating helpers for each of the options that would be self contained, they could maintain the state themselves.
Another cool option would be to create a tree view, where the root level is your server and next level is database. Load the data into a ViewModel so that it can be used as the data source for a tree view. It seems like a nice interface for what you have.
Believe it or not the Microsoft site is a great place to start when learning MVC
http://www.asp.net/mvc
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.
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.