{'coded' : 'clouded'} If it is possible in JavaScript, it is possible in Lightning

Yes, it works. I have recently posted this article related to the lightning predefault link from Spring '20. Using such things will take the users to Lightning, but we might have some old-timers who still wanna stick to classic, so this case they might see two buttons/ two links one for classic and one for lightning, sometimes it gets uglier.... Just when you think that is all bad, you might end up adding or changing field definition or record type...!!! As Homer Says D'Oh! If only you knew how to put all these together, right?!? Turned out we could! We can use URL hacks in Lightning now, and we now know if the user is on classic or lightning using $User.UIThemeDisplayed in your button/ link editor. The only complexity here is, using them both in one big formula... we have to  be really careful about the merge-field expressions... Following the use case from the previous post,  Lightning URL Hacks/ Predefault fields in lightning ,  We dont rea

Remember those days when you showed off the non-code solutions to the clients and felt really awesome with their reactions... and you did this after the demo. .. And we proudly called them URL Hacks... even though its not much of a hack, 😉, it was just passing parameters. But it's all gone with Lightning. Boy, did they hate it when those URL buttons didn't work in lightning? I mean, it was so convenient for the users, defaulting certain fields is what they wanted, they have it on so many related lists. ... And then there were Quick Actions, Salesforce promoted them heavily for replacing custom buttons, javascript buttons etc... But it quite didnt hit the spot, I meant, they were fine. Still they are useful in some places. Then, just to give the users more productive tools, we ended up overriding the new button or creating a custom component etc... We have this force:createRecord actions in aura components, without having to create a lot of code, we can use the e