Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Nintex Apps and Code

Admins can use Nintex Apps to create their dream UI with no code (no kidding), but that doesn't mean Nintex Apps implementations can't be dramatically extended with code. As a developer, you have the tools to create powerful in-page JavaScript snippets, custom Nintex Apps components tailored for your use case, or a beautifully-styled user interface that takes advantage of your existing Apex code. The sky's the limit!

However with great power comes great responsibility—and presumed knowledge. Before you begin, you must have a basic understanding of Nintex Apps as a web technology and the web languages Nintex Apps makes full use of, including HTML, JavaScript, and jQuery. Tutorials for these languages are beyond the scope of our documentation, but many helpful and free resources exist online, such as the Mozilla Developer Network (or MDN):

As a developer using Nintex Apps, you can also make heavy use of the Nintex Apps JavaScript API, which is linked in this site's navbar. Our API documentation is always growing, so check back frequently and use it as a reference if you encounter functions or objects you are not familiar with and would like to know more.

Before You Begin

As you may have guessed, the material in this developer guide is aimed at developers. If you are a database administrator, a lot of the content in this section may not be applicable to your expertise. While we'll do our best to guide beginners along, please know that in this guide, code will be used. If you feel out of your depth, or would like to see if there is a declarative option for what you wish to accomplish, please visit Concepts.

Still with us? Congratulations! But don't think you can get by in this Dev guide without knowing the basics. If you do not have a working knowledge of Nintex Apps's declarative functionality, please familiarize yourself with Nintex Apps Concepts before proceeding. (You wouldn't let a doctor operate on you if they hadn't taken an anatomy class!)

If you have not read the topics below, we recommend that you take the time to do so now:

  1. The quick start guide
  2. Connect to your data
  3. Assemble your pages
  4. Deploy your pages
  5. Adjust for Maximum Productivity

Going forward, it is assumed that you already know the Nintex Apps Admin topics covered in these five items, such as how to include fields within a model, modify a component's properties, or use the action framework. If you don't have that knowledge, you may have trouble following this guide.

How You'll Interact with Nintex Apps as a Developer

Something to remember as you begin your developer journey: Nintex Apps was built with Nintex Apps. Each part of Nintex Apps and its components is either a Nintex Apps page or a static resource assembled with the Nintex Apps JavaScript API (with a little extra magic thrown in).

In the same way that you use the Nintex Apps tool to create your UX, you'll be using the same developer tools we employed to build our product to extend yours. So what does that look like?

Extending Nintex Apps with JavaScript

JavaScript is essential to expanding Nintex Apps as a developer. You'll be writing, debugging, and otherwise completely living in JavaScript.

Although we continue to add additional core Nintex Apps components over time, we've made it easy for you to create your own snippets and custom components using Nintex Apps's JavaScript API. To get started, check out our JavaScript overview, our guide on using snippets.

Invoking Apex Logic

If you're coming from a Salesforce background, then you've probably written a lot of Apex to support your business needs. No need to abandon it—we'll teach you how to invoke and use all that Apex within Nintex Apps.

How Nintex Apps Accesses Your Custom Code

Whether you're using a new custom component or invoking Apex—you'll be doing so by storing the code in a resource that can then read by Nintex Apps. There are three types of resources you'll be using to do this:

  • Inline resources: Primarily for one-off uses of code within single pages. Mostly, this takes the form of inline snippets. Some examples include creating a custom JavaScript action or invoking Apex.

  • External resources: If you have your code stored elsewhere, Nintex Apps also allows you to use external JavaScript. Simply have your resource URL handy.

  • Static Resources: If you're consistently using a piece of code—such as a JavaScript snippet—if you're building a component pack for your custom component, or if you're an ISV developing a managed package, you should store that code within a Salesforce static resource. Static resources are the most dependable way to use code in conjunction with Nintex Apps, and they have a variety of advantages:

    • Static resources can be cached, leading to lower page load times.
    • They can be stored in a source control repository _separate_ from your Nintex Apps pages.

    In short, if you'll be extensively using custom code with Nintex Apps for Salesforce, do so using static resources.

In addition to these methods, you can also directly interact with the Nintex Apps JavaScript API from your browser's console. Useful for experimentation and debugging, you should become familiar using the browser console in conjunction with Nintex Apps.

Inline resources and page support files

Note:  In previous releases, to abide by security guidelines for functioning within Salesforce's Lightning Experience, Nintex Apps stored each page's inline JavaScript code within a Salesforce static resource known as a page support file. As of release 12.2.0, page support files are no longer needed for inline resources. If using 12.2.0+, you may delete any existing page support files within your org.

Custom Code and LockerService

While Nintex Apps for Salesforce, its features, and its components are LockerService compliant, you must ensure that your own custom code is compliant as well. Many new security rules and modern JavaScript standards are enforced within LockerService, such as " use strict " and others. Additionally, forthcoming Content Security Policy (CSP) restrictions will be implemented as well.

If your Nintex Apps site includes custom components or snippets, ensure that code follows Salesforce's Developing Secure Code.

Also note that, if you've implemented server-side behaviors with Apex code in custom components, these behaviors will no longer be possible within LockerService.

Note:  This applies to both inline resources and static resources.