Note: This post, along with any future posts will be written for first-time AgilePoint NX application users, not experienced developers.

---

I’ve been building process-based applications in AgilePoint NX (AgilePoint) since 2017 for the largest community and technical college in Minnesota. While I spend a large portion of my time building AgilePoint applications, I wear other hats at my job. I’m also the electronic forms (eForm) manager, trainer, and project manager. To better organize my responsibilities, I use Scrum framework to manage projects.

AgilePoint allows me to build process-based applications that include automated workflow processes, eForms, email notifications, third-party software integrations, and data recording. As of December 2020, I’m building applications in AgilePoint NX OnPremises v.7.0 SU2.4. AgilePoint released their latest upgrade, version v8.0 earlier this month.

When I look back at my first experiences with AgilePoint, one of the assumptions I made was that building applications was going to be fairly clear cut as long as I read through AgilePoint’s software documentation. You see, back then, I was old school. I believed that if I did A and then B, my result would be C. Well, I’m here to tell you that it’s not that simple. You can’t just read documentation, build whatever you want, and then publish your work. You can’t assume that something you build with relative ease will function with no issues. At the end of the day, it’s A to Z, not A to C because there are so many other steps involved in the application build process. To get from A to Z, you are going to have to think about what makes up the rest of the letters between A and Z.

So, before you begin building your first application in AgilePoint, below are a few things I wished I had known before I started building. I hope these tips help you with your start in AgilePoint.

Know Where to Go for Help

There are a few online resources that you can use to help you when you’re stumped.
When I have a AgilePoint question, the first resource I visit is their documentation site. To better understand AgilePoint’s documentation, you should familiarize yourself with their terms by reviewing their Concepts page. In my experience, knowing what to search for is half the battle.

I also recommend visiting the AgilePoint Support Portal to search their knowledge base or get feedback from community members. I like to review Community posts before I submit a help desk ticket or request a mentorship appointment, just to see if anyone else in the community has experience a similar issue or has come up with a solution.

You can also visit Nishant Shrivastava’s AgilePoint’s blog for the latest AgilePoint news.

Plan Ahead

To avoid development delays, you’ll want to get application requirements from the product owner before you begin building. This initial step in the building process is important because it allows you to determine important components of your application (e.g., activities, task owners, email templates). Knowing all the application requirements will allow you to set sprints goals, sprint reviews, and a reasonable publication date.

To assist me with this initial step in the process, when I receive a new request for a new application, I provide a project binder to the product owner. This binder must be completed by the product owner and reviewed before I begin building. Before COVID-19, the project binder was a physical binder. Lately, the binder is a folder titled “Binder” within a dedicated Microsoft Teams channel that includes a copy of my eForm Project Service Level Agreement (SLA) and other project-related documents that assists me in obtaining the information I need to build the request AgilePoint application.

Save as You Build

As far as I’m aware, AgilePoint doesn’t have an autosave feature. To avoid losing work you’ve done, get into the habit of saving your work in AgilePoint by using the keyboard shortcut CTRL+S or clicking the Save icon. This suggestion may seem like a no-brainer, but I don’t have enough fingers to count the number of times I’ve lost work because I unexpectedly lost Internet connection. I now save my work every few minutes while I’m building or after a major change.

Build for Users

When designing a new application, consider the type(s) of users that will be involved, how they’ll use the application, and what type of devices (e.g., desktop PC, mobile phone) they’ll be accessing the application from. I recommend conducting user research to determine the best way to build your eForms and processes.

It doesn’t hurt to mention that if when I’m building an application for another employee to eventually manage, I build the backend of the AgilePoint process model(s) to be as easy to understand by keeping the mapping as clean as possible and the naming convention consistent.

Build A Rough Draft

Since AgilePoint organizes form controls (form fields) in the Form Variable tab of a process instance in the order form controls are created in the application, you want to make sure that you have all the form controls you’re going to use, in the order they’ll be laid out, mapped out before you start adding them to task form. Otherwise, if you add a form control to the top of a form after you’ve added a bunch of other controls, you’ll always have to remember to scroll to the bottom of the Form Variable page to see the form control’s value. This may not seem like a big deal right now but after you’ve built a dozen or so applications, you’re not always going to remember the form variable order of a specific application.

To avoid out of order form variables, one of the first things I provide the form owner with after the project binder is reviewed is a rough draft of what the Report View of the application task forms will look like. The report view form allows the product owner the change to see how the form controls will be laid out and how they’ll function. This view also provides the product owner the chance to make any changes to the existing form controls, request new form controls, the removal of a form control(s), or adjust the layout. Once the rough draft of the Report View is approved by the product owner, will I finalize form control details (e.g., internal names, validations, help text) and begin building the process model(s) of the application.

Test As You Build

When I first started out, I’d wait until I finished a process model to test the activities and process out. Over time, I realized that this method of testing often caused me to spend more time trying to find the cause of a failed test because there were many more factors involved.

To effectively test an application, you should test during the building process and afterwards. Every time you add a new activity or condition to a process model, you should publish the application and run a test submission (process instance).

To get the most information during testing, I recommend:

• Updating the default process name(s). This will allow you to quickly identify your test submissions.

• Updating the Status and Error Message properties of an activity in process model so that you can easily identify which activity is causing an error.

• Testing web responsiveness on actual mobile devices so that form layout results are more accurate. Even though AgilePoint does allow you to preview a form in desktop, tablet, or mobile screens, these devices have various screen sizes.