Introduction

The possibilities are truly endless with NetSuite. So, when you receive a request for a custom solution, it can be challenging to determine whether the solution can (or really should) be built directly in NetSuite or whether an alternate solution is required.

In this blog post, we will explore an example request where there are solutions external to NetSuite that could be implemented and potentially connected to NetSuite, but instead, we decide it is more efficient and effective to build the solution directly in NetSuite.

The request

Imagine your end users have requested a bank account management solution. If you take this request at face value, many solutions (external to NetSuite) can solve the challenge of managing a large number of bank accounts.

After sitting down with your end users, you confirm that the requirements likely do not justify implementing a new application. Here are the requirements:

1. One source of truth for key bank account data points, e.g., bank name, number, address, type, etc.
2. Link each bank account to its corresponding account in the Chart of Accounts
3. Access all banking documentation from that same source of truth, with documents stored securely.
4. Capture the history and audit trail of bank account signers to support compliance reporting, e.g., FBAR reporting.
5. Have the ability to easily manage user access and restrict the ability to create/modify bank account data points.

With these requirements, how should you think through solutioning? Let’s explore.

The thought process

As I read through the requirements, some key things caught my attention.

1. New data points - that sounds like custom fields
2. Link to Chart of Accounts - that sounds like a custom list/record field
3. Access documentation securely - that sounds like the NetSuite file cabinet, with group permissions
4. Capture audit trail - NetSuite has very robust audit trail functionality
5. Manage user access, consider create/edit access - that sounds like NetSuite user roles and permissions

In short, each of these requirements appears to be something NetSuite can solve with out-of-the-box customization.

Given your end users are looking for a single source of truth, it would make a lot of sense to track these data elements with associated files under a separate database table. In other words, leverage a custom record. Going this route also allows for the most flexibility when it comes to user roles and permissions.

You should still go through a typical “Build vs Buy” analysis, but you should quickly arrive at the decision that these requirements can be supported with a relatively simple custom solution built directly in NetSuite as opposed to paying for a solution that is external to NetSuite.

Now that you have determined the appropriate course of action, it’s time to execute.

The execution

We won’t review the lifecycle of running a NetSuite project in this blog post, but we will highlight some of the key steps and NetSuite-specific solutions that should be employed.

Step 1 - Playback requirements

Make sure you are aligned with your stakeholders on requirements. Challenge them on additional functionality needs - perhaps there are “nice to haves” that can be added to the project scope or requirements that are really “nice to haves.” This step is critical.

Step 2 - Solution design

This solution will require multiple connected custom records. To keep it simple, the parent custom record should contain all of the bank account data points and reference back to the Chart of accounts.

As for tracking a separate audit trail of bank account signers, those should be tracked under a separate child custom record. This achieves the requirement of maintaining a single source of truth while granting the flexibility of tracking a separate audit trail for changes to bank account signers, which will be useful for reporting purposes.

A new file cabinet folder should be created, and access restricted to that folder via the creation and assignment of a custom group. The group will then dictate who has access to the file cabinet folder (and its contents). This provides both the security and the flexibility required.

User access to the new custom records can then easily be managed through the standard user roles and permissions functionality, under the “Custom Record” subtab.

In summary, the solution requires the following customizations:

• Custom record x2
• New file cabinet folder
• Custom group
• Custom user role permissions

Review the solution design with your stakeholders before moving into the build phase of the project.

Step 3 - Execution and deployment

Once the solution has been built and tested, it is ready for deployment. Deploying NetSuite solutions manually can be time-consuming, not to mention the risk of human error. The good news is that NetSuite provides various out-of-the-box solutions, such as SuiteBundler, Copy to Account, and SuiteCloud Development Framework (SDF), to support this process. Each solution has its own advantages (and disadvantages), so you will need to review these to see which makes the most sense, depending upon the complexity of the custom solution and your skillset.

An alternative solution to consider for deploying NetSuite custom solutions is Salto. Salto is a SuiteApp that empowers NetSuite Administrators and Developers by facilitating faster deployment of these solutions. Salto has the added benefits of providing environment comparisons and allowing for simple version rollbacks if something unexpected occurs.

Now that you have deployed the solution to Production, the final step is to load the bank account data and documents. Don’t forget to leverage CSV imports where possible!

Useful references for this custom solution

• Custom Records
• File Cabinet
• Custom Groups
• User Roles & Permissions

For more information on expanding your NetSuite toolkit and how to think like a NetSuite Pro, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.

Final thoughts

The key takeaway is that you should not always assume that you need to purchase a third-party solution when end users request a new “system.” Take the time to fully understand the requirements and think through where there is overlap with NetSuite core functionality.

At the same time, not all solutions should be built directly in NetSuite. Consider the availability of internal resources (and skillset) before jumping into a custom NetSuite solution. You may need to leverage external contractors for support and should factor that cost into any return on investment (ROI) calculations.

Lastly, don’t forget how powerful custom records can be when used effectively. If you’re not using them today, then you probably should be - check out this article focused on custom records to learn more.