This blog post is generally relevant to all versions of SuiteCommerce and SuiteCommerce Advanced.
We've talked about what's important for developers to know about in the 2019.1 SuiteCommerce and SuiteCommerce Advanced bundles, but the core NetSuite release might have slipped you by. We do document a number of platform improvements in the release notes and some of the ones we're going to mention today are covered by those notes, but there are also improvements in other areas that impact you as commerce developers.
Thanks to Florencia Meilán for spending time highlighting a number of these for me.
Release Preview Opt-In
If you used a 'release preview' account last release, then you will receive a release preview account for 2019.2 by default. If you haven't already opted-in, consider it for your organization. It will allow you to test new releases ahead of time, giving you, at a minimum, the ability to be among the first try out new features, but also new opportunities to try out any customizations that you have made to your instance to make sure they're compatible.
Mandatory Two-Factor Auth (2FA) and Integrations
You'll remember that we have phased in the requirement to use 2FA for any account that has significantly powerful account access (such as admin accounts). Exemption periods for any integration that uses highly privileged accounts is now over and you are no longer able to use these types of accounts without providing 2FA credentials when requested. In other words, we would strongly recommend you migrate away from using roles that are so privileged as to require 2FA
This also applies to the developer accounts, and you should have migrated to using the SCDeployer role. Refer to our documentation if you're unsure.
Deprecation of the Full Access Role
In a similar, security-themed vein: we are also deprecating the 'full access' role. As of 2019.1, we have introduced the following changes:
- It has been renamed from Full Access to Full Access (deprecated).
- You cannot assign the full access role to new users.
- When users log in with the full access role, they see a notification indicating that the role is being deprecated.
- A new permission called Core Administration Permissions is available. This permission provides access to some of the same functions that are currently available to users with the full access role. You may be able to use the new permission as an alternative.
You should review all the users who use the full access role. Ask whether they need such priveleged access to do their job role, and consider the following:
- If they don't need that level of access, assign them an alternative role and encourage them to use it as soon as possible
- If they do, analyze their needs and determine what specifically about having full access they need: then find them an alternative role that suits those needs
Copy to Account (Beta): Copy a Custom Record from one Account to Another
Copy to Account is a beta feature. The contents of this feature are preliminary and may be changed or discontinued without prior notice. Any change may impact the feature’s operation with the NetSuite application. Warranties and product service levels do not apply to this feature or the impact of the feature on other portions of the NetSuite application. We may review and monitor the performance and use of this feature. The documentation for this feature is also considered a beta version and is subject to revision.
If you're interested in trying out this feature, you can enable it in Setup > Company > Enable Features.
What it does is let you copy a custom object from one account to another quickly and easily using the NetSuite UI. It's available to users that have administrator access to more than one account, so it is particularly useful when you are working on a sandbox or development environment and want to quickly copy across a customization from one to another.
Commerce Categories on Item Records
You can now access commerce category information and reporting while viewing item records.
When viewing an item, you can see information such as what site, commerce catalog and commerce categories it is assigned to, whether it is active and its start/end date (ie its visibility in those categories).
For you fans of saved searches, you'll be pleased to know that these details are also available for criteria definitions and results.
Shopping Domains in System Email Templates
By the way, if you're not already using system email templates and want to find out what they are, I strongly suggest taking a look at the blog post I wrote on them.
Anyway, you can now reliably identify the shopping domain through which an order was placed even if the domain is not marked as the primary domain. The domain name is available in the synthetic field
domain, which is now included in the default system email templates for web stores.
Out of Stock Items in Web Store Emails
On the same subject, you can see use the new
itemAvailabilities synthetic field to return the number of items available for sale taking into consideration the items available in warehouses minus those already committed to orders. This makes it super useful for calculating whether to consider an item out of stock or not.
Deprecation of Sandbox Domain
The domain used by sandbox instances is no longer available as of February 28, 2019. You can no longer use system.sandbox.netsuite.com to access them, and they have now all been moved to system.netsuite.com.
CNAME Flattening is now Supported in SuiteCommerce
If you really want to use your root domain for your webstore and other services (such as email) then you'll be pleased to know that we now support CNAME flattening as long as your DNS provider does too. The key drawback in running a root domain for both your webstore and other services is that it used to mean that you couldn't use a CDN (and we strongly recommend using a CDN for your webstore).
For the record, we still recommend using a third-level domain such as www.example.com or shop.example.com for your webstore as it'll avoid a lot of headaches (but we know that a lot of people love the aesthetic of example.com).
SuiteCloud Development Framework (SDF)
We believe that SDF offers a lot of opportunity for SuiteCommerce developers, and we're going to be throwing a lot of focus on it over the coming months and years. However, while its use is not mandatory for extension development, we do want to encourage curious developers to begin to take a look at it. Its benefits are especially apparent when you consider that dipping your toes in this particular pool offers up opportunities to development and integrations with other parts of the NetSuite ecosystem.
Application Publisher Name when using SDF for SSP Applications
If you use SDF to publish SSP applications, you must now use the Application ID as the Application Publisher name.
SuiteApp Marketplace Permission Replaces SuiteBundler Permission
As of 2019.1, the new SuiteApp Marketplace permission replaces the existing SuiteBundler permission. What this means is that while it includes all of the SuiteBundler permission capabilities, it adds:
- Access to the SuiteApp listing page in NetSuite
- The ability for customers to install SDF SuiteApps from the SuiteApp Listing page
- The ability for customers to uninstall SuiteApps from the Installed SuiteApp List page
- The ability to view the Deployment Audit Trail page
New Location for Installng SDF SuiteApps
As part of the transition from SuiteBundles to SuiteApps, we've added the aforementioned pages to NetSuite. What's the SuiteApp Listing page? Well, it's a central location in NetSuite for a user to find and install SuiteApps created using SDF.
Even if you don't plan to distribute your customizations outside of your organization, using SDF SuiteApps can make your job easier because they can contain required NetSuite objects such as a custom fields and records, as well as configuration settings.
For now, note that currently only SuiteApps from the com.netsuite publisher ID are available on the SuiteApp listing page, and that they are all manage SuiteApps. You'll also need the SuiteApp Marketplace permission to access the page.
New Standard Developer Role for SDF Development
Previously, when doing SDF development, it required an account that had administrator priveleges (or an account created by an administrator that had other powerful priveleges). As you'll probably guess, we're not a fan of this, so we've standardized the process so that there is a now an easy-to-use Developer role that SDF developers can be assigned to.
Just note that you must customize the new developer role when working with SDF projects that either impact standard record types or require additional permissions that are not included with the standard Developer role. The customized role must have the appropriate permissions enabled for all the standard record types your project affects.
SDF SDK 2019.1 is Available for Download
Finally, if you are interested in trying it out, you can get our SDK. It contains the SDF CLI, which you can use with your own IDE to create SDF projects, including SDF SuiteApps. For you advanced users, you can also batch/shell scripts that use CLI commands to automate project validation and deployment processes. If you do decide to integrate them into your IDE, then you can use them as replacements for the SuiteCloud IDE. Neat!
Final Thoughts and Links
Don't forget to read all of the release notes for each release, especially the Commerce Platform notes.
As for SDF, I hope it's clear that we think it is going to be a big deal for commerce developers over the next few years, and while I encourage you to take a look yourself, I recognize that this can be quite daunting. I will look into what we can provide on the blog to aid the process of getting started.
For more information on what I mentioned here: