This message was deleted.

ACS do it too. Most frustrating. They should engage with the client and ask for their naming standards

Many clients use more than one partner during the span of their Netsuite total use. It helps the partner to distinguish their customizations from others. But dont misunderstande me, I agree with you. They could keep track on that without painting Netsuite with their sometimes silly company names.

Branding to help you remember who did you wrong for the life of your system. 😂

In my experience, most customers do not have a naming convention/standard defined, and it helps the partner to isolate ownership, and it is especially helpful when using SDF. I don't work for a partner at the moment, but I did it for more than 3 years, I prefer to have my fields with an internal naming standard and let the partner use their naming standard this way I have some type of clear and defined isolation.

I've worked at 4 different partners everyone of them does it for this reason, not branding, not awareness just making life easier internally. As Alien mentioned, companies rarely have naming conventions, heck, good luck getting the average user to even enter a custom id for fields / searches etc. 🤭

All of my clients have naming conventions because I establish that as soon as I land. Many of the partners are cowboys and tagging their name into the custom elements of an implementation is just a part of that amateur behaviour. Isolating your changes is silly and not in the best interest of the system from a long term perspective. I'm looking at folders, records, scripts and fields all littered with acronyms from various partners over the years; this eats valuable character spaces that could be used to provide more accurate descriptions of what the custom elements actually are/do. I don't see how this helps when using SDF at all, me injecting "CS" into everything I touch isn't useful to the client or the system. Everything I build gets logged in my build log with a one-pager explaining how it was built and the requirement. If I find a field name that isn't in my log, I didn't create it, that really shouldn't matter though unless I'm trying to nickel-and-dime my clients "not my record/field/script, gonna cost you extra!" When you walk away from a client/system, you are leaving a legacy. Ring fenced elements, tagged with your name, isn't useful to the client (or future vendors) operating that system long term. I feel like the NetSuite ecosystem still has some growing up to do. #DyingOnThisHill :-)

You do you mate. 😄

You do what works for you and make you happy, but if partners with more 15+ years in business have a defined naming convention or standard it is because there is a value/reason behind it and not because of amateur behavior. Field IDs are just field IDs, if you need more context or information those fields have a help section for that.

@alien4u I understand the struggle with poorly named customizations; it’s a real issue, especially during SDF imports when you encounter field IDs like

customscript_123512

. It emphasizes the importance of following a meaningful naming convention and thorough documentation from the start to avoid such confusion.

Naming is important and serves a functional purpose otherwise we'd just accept the NS defaults. Tagging your company name is silly and is of no benefit to the system long term.

Again, do you, and what makes you happy, but I still think people doing it differently have their own reasons and I don’t think everyone doing different than you is silly or dump.

There's a whole body of literature on software and it's very clear that naming, name spaces, and hierarchies matter.

Right, I must have hit the ceiling of my competence

Most likely the case if you think the way you do it is the right way and everybody else is wrong.

I'm not saying everyone is guilty of poor naming conventions

We organize various scripts companies have worked on by folder name. This seems like a pretty standard practice to me. This allows us to better identify who worked on a customization without going into the docs to review the creator — something that fails even more if the company doesn’t provide proper jsdocs for their work.

Clearly this is something you feel strongly about, I can appreciate it frustrates you. Hand on heart all 4 of the partners I've worked for have never cut corners or made concessions to suit themselves. (certainly not in the development teams). It sounds like you feel partners are the work of the devil which makes me sad, I take pride in what I do and making sure a customer is happy with my work, not just my employer. 😞 netsuite

It's also the case that many people will just copy poor practice because they don't know any better.

@NElliott Maybe you’re the exception not the rule? I too have had poor experiences with consultants, but they didn’t have 15+ years experience either to compare against.

salesforce_invoice_id salesforce_craig_invoice_id I can't possibly guess which name is better... 🙄 scripts/customGL/ scripts/project_alpha/netsuite_partner_name/team_ajax/ Which folder structure makes more sense?

Initials allow me to know the person who worked on a script, saved search, etc. is no longer there to ask. If they are still available, it means we know who to look at for the best answers for why a script does something or to further manage that object they created originally. This is a practice NetSuite encourages, and probably for good reason.

I know netsuite encourages it, I saw it often when i worked there. I'd message the consultant that built a script to find out he'd left the company two years ago.

@Craig, while everyone’s situational context is unique and it’s important to adopt practices that serve your organization’s needs, it’s also valuable to consider the broader ecosystem. Many NetSuite users adhere to the recommended naming conventions because they typically ensure smoother transitions and collaborations across diverse organizations. If you prefer to establish different guidelines within your organization, it would be beneficial to clearly articulate these to any incoming consultants or partners before they commence work. This proactive communication helps maintain clarity and cohesion in multi-developer environments.