I’m considering trying to find a way to version our netsuite ‘schema’ (custom record types, custom fields, lists etc). In terms of development, we generally have a way to version our db schema. A contributor writes some code that requires a new field, we create a migration script (class, whatever). With the migration code we have way to progress “up” to the version that includes the field and a way “down” that returns the schema to the state before the field was added. An example of a library that provides this would be https://fluentmigrator.github.io/ - if you’re a .net person you might be familiar with Entity Framework migrations, Java folks: hibernate has code for schema migration. Is anyone familiar with a tool/library/feature of Netsuite that follows this pattern of versioning their schema changes?

If I've understood correctly what your desired outcome is then no, there's no way to do this and there really can't be. "schema" changes can be made via sdf, and those could somehow use a tool (that I don't think exists yet) to track the schema changes there... but I don't see how you're ever going to get the schema changes from ... 1. manual changes by NS admins in production 2. Bundle Installs / updates 3. SuiteApp Installs / updates

There’s no way to do this via SDF- that’s what I’ve found as well. I was hoping to find a netsuite api that I could use to wrap with a very rudimentary wrapper to generate custom record types (and add custom fields) and manage the netsuite schema. Looks like Netsuite doesn’t wish to expose those apis: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N3204194.html#Custom-Record:~:text=You%20can[…]isting%20custom%20record%20type

Not sure if that's exactly what you're looking for, but AFAIK Salto (full disclosure, I'm with Salto) supports it -- including reading all the definitions of custom record types and fields, version controlling these in Git, and deploying changes to them (including rolling back, etc.). It can also read and write the records themselves if needed. See https://help.salto.io/en/articles/7876742-fetching-custom-records-in-netsuite . You can play with this in the 30-day free trial at salto.io if it piqued your interest.

Thank you! I passed your product around. We’ve gotta do something differently. I’m frustrated at the level of technical knowledge that support provides when we have SDF issues. I would really prefer that oracle provide a api to manage custom records/fields etc but that appears to be a conscious decision to deny us that.

Thanks Joel. As far as I know, you can read and write custom record types using SDF (see https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_1526908548.html#Custom-Record-Types-as-XML-Definitions), and that's also how we implemented our support for the types and fields (the instances themselves are implemented differently). Note that these capabilities (for the types and fields) are also available in Salto's open-source project (requires a technical user, it's a CLI unlike our SaaS offering which is much more user-friendly). See https://github.com/salto-io/salto . What problems are you seeing with using SDF for that?

@Joel Musheno As others have said, SDF does not do exactly what you're describing, but to some extent I think it can serve the same purpose. Using SDF you can fetch a custom record schema, pull that into a code base that is under version control, add your fields, etc, commit and deploy. So you'd certainly be able to programatically ADD to your schema and track changes over time (using version control). But rolling back is the tricky part. If you changed an existing field type, you could roll back your commit and then deploy again, which effectively works. But one thing I have discovered is if you remove a field from your schema and then deploy, it doesn't remove the field from the record. So basically from what I see SDF supports creating custom records, adding fields, changing fields, but not so much removing fields. That you have to do manually. Hopefully this helps. I'm only a couple of months into my SDF journey and despite some annoying things, I think it's a great tool and this community provides the support Netsuite lacks

Yep, the problem is rollback for sure. We don’t have an API to support schema changes- meaning that if my QA team needs to roll out a change from a version of our codebase 3 months ago, there’s nothing that can take them back in time to a time when the netsuite schema matched those artifacts. Thanks all. Nothing that we can do.