Customer Engagement & Dynamics CRM Forum

 View Only
  • 1.  Set Different Defaults for views

    Posted Nov 10, 2022 01:16 PM

    We have a few system views that we want users to use as editable grids, and we would like them to default that way. We have other system views, and personal views, that we would prefer NOT to have users use as editable grids, and we certainly DON'T want them to default that way.

    Is it possible to set a default setting for individual system views?  In the entity itself you can select specific controls, such as editable grid, or power apps grid, but not all those options are available on the individual views themselves.  I thought we could do this in the past with personal views, but it does not appear to work for now or I have forgotten how I did it!

    Is it possible to configure some views that CANNOT be used as editable and some that CAN?  [Understanding that its game over if a user uses excel online; we have field security on some of our fields to prevent this behavior already; however, we want users to be able to update some fields on a form, but not in a view [i.e., dependent option sets, where we cannot control the dependency in the view like we can on a form]

    Sandra Devin
    CRM Analyst
    National CineMedia
    Denver CO

  • 2.  RE: Set Different Defaults for views

    Posted Nov 11, 2022 06:29 AM
    Great questions!

    Also - is there an easy way to make some columns always non-editable?

    Donal McCarthy
    BrightWork 365 Solution Architect

  • 3.  RE: Set Different Defaults for views

    Posted Nov 14, 2022 10:48 AM
    The code below will allow you to lock all or specific fields on a system or personal view related to a specific entity.  The code does not however discriminate based on specific views (but it does allow for security role testing so you can add say the system administrator and one or more other security roles that you want to allow editing on).  The code has been obscured for column names, but we use this same code across 3 entities/tables in our live environment and it will perform the locking of one or more columns (or all columns if you desire) for any views of that entity.  As you point out it will not prevent the excel online or export import (we solutioned both of those by not allowing our users either of those capabilities - pros and cons to that level of restriction).  When you add this code at the Entity level on the Events tab

    // setGridRowDisabled
    // Add this code at the entity "Event" level so that any system or personal views will have this applied to it
    // This code will lock all or specific fields on editable grids and sub-grids
    function setGridRowDisabled(context) {

    var lockrow = 0;
    var contact = context.getFormContext().data.entity;
    var crmGrid = context.
    // Get the security roles for this user to see if they have a Security Role that we will ALLOW them to do editting
    // As this role is like wearing a Superman Outfit - they can do whatever they want - kinda.
    // You can enter any special security roles here that you want to allow for overriding the locking
    var roles = Xrm.Utility.getGlobalContext().userSettings.roles;
    var hasRole = 0;

    roles.forEach(function (item) {
    if ( == "supermanjunior" || == "system administrator") {
    hasRole = 1;
    try {
    // The code here is designed to lock all fields on the subgrid if a value is present. May not be applicable to your situation
    contact.attributes.forEach(function (field, i) {
    if (field.getName() == "new_lockall" && field.getValue() == 1) { lockrow = 1; }

    // if the lockrow has been set above and the user doesn't have the superman/sys admin roles then lock all as disabled
    if (lockrow == 1 && hasRole == 0) {
    contact.attributes.forEach(function (field, i) {

    } catch (err) { alert("Error in gridrow disable row script=" + err); }
    // This section is executed if the lockrow is not set, and in this case we will lock very specific columns that we don't want users changing
    try {
    if (lockrow == 0) {
    contact.attributes.forEach(function (attribute, i) {
    var aname = attribute.getName();
    switch (aname) {
    case "new_field1":
    case "new_field2":
    case "new_field3":
    case "new_field4":
    case "name":
    var attributeToDisable = attribute.controls.get(0);
    // Lock specific fields even from Superman role users - in the example below we will lock field2 and field4 from superman but as it doesn't test
    // field1 or field3 or name those fields would be unlocked for the superman role user.
    if (hasRole == 1 && (aname == "new_field2" || aname == "new_field4")) { attributeToDisable.setDisabled(true); }

    if (hasRole == 0) {

    } catch (err) { alert("Error in gridrow disable field script=" + err); }


    Hopefully you can test and see if the above would help solve for your situation.  If anyone finds a MSFT supported way to obtain the view name and view id for testing (prefer the view id as it is more definitive than a name which could be duplicative and misleading) as having the view id would enable you to lock anything that isn't your preferred view with a little tweaking of the code.  This selective approach is less onerous than using field level security.

    William Suycott
    Jacksonville FL

If you've found this thread useful, dive deeper into User Group community content by role