CRM fields

     While using "Custom Javascript" area in Web pages, Web Form Steps etc. I found it a little bit uncomfortable in use.      The max length of 10 000 characters not always enough and if I add a compiled content then debugging is blocked.      I ended up creating dynamic script loader. It picks up a url (like "~/Areas/FolderName/scriptName.min.js") from “Custom Javascript" area. Then script checks if such a namespace exists and object is loaded. If necessary, it loads the script. The idea is very simple. Have an object loaded with master page to load JavaScript and CSS files: if (typeof (gHelper) == "undefined") { gHelper = { __namespace: true }; } gHelper.data = { addedFiles: "", } gHelper.fn = (function (window, document) { function loadfile(filepath, filetype) { var fileref; // JavaScript file from solution if (filetype == "js&q

   In this post I’m not going to compare modern MS Dynamics Crm portals but two main models which vendors use to create their products. First one we’re going to call “crm data driven” model and let’s name another one “crm loosely coupling”. Data Driven model (DDM)         Data Driven model (DDM) means that frontend pages, views and controls replicate the crm forms and respect most of crm filters and validations. DDM dictates vendor develop a platform to reflect crm architecture and rules on the front end.       Vendor’s platform can provide additional enhancement inside portal and crm. It can be frontend content management system CMS, pre-installed solutions for better web engagement experience, deployment tools, ALM kits, portal plugins, service workflow etc.       The main benefit of the DDM is ability to manage portal design and create simple business flows without writing code. It’s a true for simple pages but for complex projects it doesn’t work.        A significant