thanks for the reply. now even if i use proper (more reliable) selectors, will this guarantee that my JavaScript will not break if we apply a CU which might update the markup? i totally agree with u that using a selector which mention to select an element which has an id start with for example "PMStatus" ,,, will be more robust that saying to select an element which has specific id such as "PMStatus_7d7b4035-d3e4-468e-8894-29905e54b35f_$DropDownChoi‌​ce" ..

..... but will this make my javascript 100% robust or it will just minimize the risk that it will break.. i mean is there a guarantee that the field id will always (now and in the future) start with the field internal-name??

No guarantees.. you are dealing with Microsoft of course... they killed many technologies and CSR is gone in Modern Experiences as well.. But yes, if the internal name is there you can (fairly) rely on it. The only guarantee in life we have is ...

but as I mentioned before the ids will start with the internal names and will not be exactly equal to it .... so not sure how it will work in the future...not sure why Microsoft did not just render the internal name as the ids...

second question is there another approach I can use rather than relying on built in forms and JavaScript to deliver the requirements.. as seems this approach have some drawbacks ... or it is fine to use it ???

I would consider using the SPUtility.js and SPServices.js libraries. If you are concerned about future proofing, one would assume the maintainers of those libraries will update them should MS pull the rug out from under us on something. For example, they did with a CU for SP2013 and required fields.

@mannaggia i am not sure how i can use SPUtility.js and SPServices.js to achieve what i am looking for.. can you provide some examples or provide more details on this please? second question,, is using built-in list forms + javascript to implement my requirements a wrong appraoch ?

Those are Frameworks built on top of jQuery, which in itself is built on top of Vanilla Javascript; Instead of writing a few lines of JS code yourself, You will be stacking a lot of dependencies.. not to mention the 300+ KB you need to load... with UCAs or JSLinks. But if you slice your sandwich with a chain-saw then who am I to say you are doing something wrong.

@Danny so even using these libraries will still be facing the same issues of having to reference the fields ids ??? Generally speaking is using built in list forms and JavaScript to implement my requirements a valid approach .. as at this stage I am still confused...

Libraries/Frameworks are like kitchen appliances; they make part of your job easier... but no one tells you also need to clean those machines. So yes they will solve some of your problems.... There are pros and cons. If you add Frameworks you have to keep track of versions... Microsoft Fabric (its MS take on Bootstrap) as example... Microsoft made breaking changes in v6 and now 'old' code with the new library does not work. JSNative IS more work, but it saves you from upgrade issues or doing the dishes. I use Frameworks, but know Why and When based on experience. You have to learn for yourself

@Danny'365CSI'Engelman my concern is not with the easiest approach ,, as i can easily manage these requirements using javascript .. but my question was is how reliable is to depend on the built-in ids and titles... so till now i am not sure how i can improve my approach of using built-in forms+javascript, and if my appraoch is robust enough or not??.. and is using libraries will make my approach more robust ?? i am trying to keep my question within its intended boundaries...

It is completely up to you if you want to use that Its-Amazing-Mike! Framework. Rest assured you can ditch the majority of your work and rewrite it for Microsofts Modern Experiences, : youtu.be/9N5BbFS0img

@mannaggia now i totally agree with you now using SPUtility will be more reliable as it provide functions such as SPUtility.GetSPFieldByInternalName(strFieldName) will be better than referencing the actula fields ids...

@johnG, if you do a web search, you can find SPUtility.js and SPServices.js. You will also need jquery. Include those on your page. To disable a field like "Customer Name", you use SPUtility.GetSPField("Customer Name").MakeReadOnly(). You don't need to mess with internal names. Same with checking Status and disabling the Approver field. Use if (SPUtility.GetSPField("Status").GetValue() == "Canceled") SPUtility.GetSPField("Approver").MakeReadOnly(); As for checking the security group, that's where SPServices.js can help make things a little simpler calling some of the SharePoint services.

SPUtility.GetSPFieldByInternalName(strFieldName) under the hood still works on those same Internal and IDs see line 182 of the SPUtility source .. lines and more lines of JavaScript to analyze DOM elements and parse an Internal name... IF the Internal name of a Field changes, SPUtility is not going to save your ass... actually SPUtility is more dangerous then writing your own DOM selectors.. because SPUtility is hardcoded on something being exactly 19 characters (line 185)

@Danny'365CSI'Engelman i think Danny you need to use more appropriate words in ur comments :(

@Danny'365CSI'Engelman now of course if i change the column internal name (which i did not do before) will mean that i need to update the SPutility code.. but atleast i will be sure (or more confident) that my script will be working fine in the future if i do not chnage the internal name,, unlike replying on the non-friendly built-in columns ids which might change after updating our sharepoint farm .. so i did not get ur point? you are against using SPUtility() ?? but seems it will be better compared to using pure javascript which reference the fields ids ...

.. so what is better to select my field based on its id inside the markup as ("#PMStatus_7d7b4035-d3e4-468e-8894-29905e54b35f_$DropDownCh‌​oice) when using pure javascript? or to do something as follow using SPUtility var myField = SPUtility.GetSPField('PMStatus'); ?? i thing SPUtility is wide better and more robust...

@mannaggia one time i added a content editor web part inside my list view.. then i realized that that list view page stop working on the defualt mobile interface,, so not sure if this will be the case if i add the content editor inside the create form.. any way this is not my main concern... but i added as a general info ...that content editor webparts can break the page on mobile interface..

@mannaggia now i tried using SPUtility to achieve what i am looking for.. but i find it hard to capture when the Managed Metadata field is changed.. i opened another question regarding this on sharepoint.stackexchange.com/questions/216376/… .. so if you can check it??