There is a little-known quirk with Nintex Automation K2 SmartObjects and how they handle null values, or rather, non-values.

I am not a computer scientist so I cannot comment on whether null should be considered a value or not, but I am intentionally framing the topic in this manner as it is that line of thinking in which null is a value that creates a very frustrating problem for the unaware.

The issue is if the service broker feeding your SmartObject, be it a REST service, MS SQL, Oracle, etc., returns a null value for a property you are evaluating in a conditional statement in a SmartForm rule, you will never receive a true if you are evaluating for “Is Empty”.

Curious Indeed.

There have been other areas in K2 SmartForms where type evaluation didn’t happen as expected. Form and view parameters, for example, can be picky about where the data type is text or number regarding how those evaluate within conditional statements. I have read Nintex Community posts on this topic, so I do know there is documentation on the web highlighting this behavior.

The null situation has caught two different customers in the last six months, so I thought I would give it some attention.

It can be a frustrating problem when the SmartForm you are developing just will not work the way you expect even though all the data you are seeing on screen says it should be. (Shout out to Rick, you know who you are.)

I’ve assumed that a null was empty, but null is null. SmartForms doesn’t have the C# equivalent of IsNullorWhiteSpace, so what is a developer to do?

In all the instances I have experienced, we were developing either custom services or stored procedures, so we were able to change the behavior instead of just returning null.

However, if you are in a situation where you do not have the ability to control return values, I can think of a few approaches you may try. I have not tried these personally, but this would be the path I would go down if I were in your situation.

The simplest approach is you might try assigning the SmartObject property as the value of a hidden data label on the view or form and then evaluate the label’s value not the SmartObject property directly.

If that fails, you could then try creating an expression (the little fx at the top of the design canvas in K2 Designer), that leverages a combination of functions to attempt to validate the property and return a value that could be evaluated.

Depending on the exact scenario it may take two data labels: one to hold the SmartObject property’s value, and one to which you assign the expression to store the result. It would be that second data label that you could then use in your advanced conditions.

If all else fails, sometimes it is a good idea to just take a step back and rethink your logic. Is there a different way to evaluate logic?

I would imagine that the behavior isn’t necessarily with SmartObjects themselves, but rather how the JavaScript powering SmartForms handles the scenario as I don’t recall having this issue inside of a K2 workflow.

Hope this helps a would-be K2 developer out there that is ready to rage quit because no matter what they do that seemingly valueless SmartObject property never evaluates as “Is Empty”.

Have you hit a quirky evaluation issue before in K2 SmartForms? Have you noticed this issue? Comment and share your thoughts.

The conversations online, along with Nintex’s increased messaging about the end-of-life of K2 blackpearl, have raised many questions. So, let’s address a few of them and bring some clarity to what is becoming a hot topic.

For some background, I have two clients who are actively involved in both the migration and upgrade processes. I say “both” because while closely related, these are two different undertakings, and it is essential to understand that distinction.

What is a K2 blackpearl migration?

When discussing K2 blackpearl migration, we are referring exclusively to workflows built and deployed with the desktop-based tooling, which reached the end of this year. Workflows built in the legacy tooling cannot be maintained by the newer K2 Designer, nor can they be imported.

Migration of a K2 blackpearl workflow is a migration in concept only. In practice, it is a full rebuild of the workflow. Any SmartObjects or SmartForms created as part of a K2 blackpearl solution do not need to be updated other than updating any rules to use the new replacement K2 workflow.

Additionally, any custom .NET applications that use the K2 client libraries will continue to work as before, since none of the APIs have changed, including SourceCode.Workflow.Client or SourceCode.Workflow.Management and are still fully supported for the new designer workflows, just as they were for the K2 blackpearl based ones.

Why rebuild?

If you are wondering why import isn’t an option, you aren’t alone. The primary difference between the two versions is the change in design tools, moving from a desktop-based experience to a web browser, and the limitations imposed by that shift.

The blackpearl lineage of tools was all XML-file-based, whereas the new tooling is RESTful & database driven using JSON for workflow design artifacts.

Along with changing the tech stack, an opportunity was seized upon to apply the lessons learned from the first two generations of design tools to craft a more modern, intuitive design experience.

Design is the keyword. The changes to K2 workflows are a design-time consideration only. The K2 workflow runtime did not change. To reiterate, any tooling or custom applications created to manage or interact with K2 at runtime are still valid, with a couple of notable exceptions.

What changed?

With the technology shift and the refinement of the design experience, there are four changes that also fuel the need to refactor your workflows and update any associated custom applications.

• XML process data fields have been removed.

• Activity data fields are no longer.

• Custom code isn’t supported in design tools.

• Activities and Events were replaced with Steps.

For my customers, the removal of XML data field support in the Nintex Automation K2 designer was the most influential in driving the push to refactor. XML data fields were introduced in the early days of K2, well before SmartObjects were introduced.

At the time, XML was the only way to store or model complex data relationships in the workflow driven by the integrations with InfoPath, one of the primary UI options for a K2 solution.

Later, understanding evolved into a pattern of externalizing data through SmartObjects, making it more accessible and maintainable. The introduction of SmartForms and the slow deprecation of InfoPath further lessened the practicality of XML as a data storage medium.

Activity data fields have also been deprecated in favor of greater use of process-level variables. It is my understanding that this was done primarily to simplify the design experience. It helps to remember that at one point, the messaging from Gartner and Forrester was the rise of the citizen developer, which necessitated a refinement of design concepts.

The removal of the Activity and XML data fields will affect custom applications, which will need to be updated accordingly. Variables are rebranded Process data fields, and no changes are required.

The ability to write custom code in the K2 design tooling was also deprecated as a part of the technology shift. The Visual Studio design experience allowed adding custom code or reference libraries that aren’t compatible with the new approach.

The focus on custom code shifted to ServiceBrokers via SmartObjects and expanded to include JavaScript. C# was the only option prior to the change.

The important takeaway is that while the technical implementation details were removed, the instigating use cases can still be addressed via other means that preserve the original intent.

Finally, the structure of how workflows are assembled changed. Activities and events gave way to Steps. This was purely a design consideration, thus making the two paradigms between old and new incompatible. Another citizen developer: quality-of-life improvement. It was a bit of an adjustment at first, but I must admit it makes more sense. For me, it was just more a matter of adjusting to the change than a functional limitation.

Why migrate?

The end-of-life deadlines are not technical limitations. Workflows are not going to stop working on at midnight on December 31 if they have not been migrated.

The motivation to migrate is access to support and security. Of my two clients, one migrated a major solution from K2 blackpearl by the October deadline due to the highly regulated nature of their industry. Being on unsupported software was a risk they were not willing to take or a conversation they wanted to have with regulators. We went live in the first half of October.

The remaining client their migration effort is ongoing. Their industry affords them a bit more flexibility in their planning. They have been using this process as a training effort for new K2 developers to skill them up on legacy solutions and K2, and I have been engaged to advise them on how to rearchitect the solutions to fit the features of the newer K2 version.

Clients who are finding themselves in this situation have obviously been K2 users for a very long time. Solutions that could be as old as 17 years old. These are obviously important processes to have been maintained and still used for that long, so migration is necessary.

There will be a level of effort associated with migration. Keep in mind that, in many instances, it is a carbon-copy rebuild. The hard work was already completed when the solution was originally built. At least, the effort will be opening the legacy workflow, starting a new workflow, and mapping the old to the new.

The effort would increase if the workflow relied heavily on custom code or XML data fields, as in my regulated client’s workflow. It required rearchitecting not only the workflow but also impacted systems and applications. If you find yourself in a similar situation, I advise you to take a moment to evaluate the solution. Understand how the workflow change will impact the solution as a whole, and take some time with the business owners to review the workflow. My client and I found out after the fact that a few steps in the workflow we were migrating could have been left out because the business needs had changed.

In the race to migrate with time as a factor, take a moment to evaluate the process. I am not suggesting a full process discovery exercise, but at least a critical look, as you may save yourself some time and effort if there is functionality that doesn’t need to be brought forward.

When to upgrade?

My clients who are migrating were already running a newer version of K2 before they began the migration. Upgrading can happen at any time, independent of migration.

The need to upgrade is driven by the end-of-life of k2 blackpearl 4.7.

Migration is a topic that was driven by the end of life of Visual Studio 2015.

The matter is slightly complicated, as the final date for both is December 31, 2025, because both the design-time and runtime components that support them are reaching the end of life.

The upgrade will only be a prerequisite for migration if your organization is not running a version of K2 5.x with the new K2 Designer. K2 blackpearl 4.7 customers must upgrade before they can begin the migration process.

Final thoughts

My recommendation is that if you are a K2 blackpearl 4.7 customer, upgrade to K2 5.7. The move is a required step on the journey to 5.9 from 4.7, so effort won’t be wasted. This will keep you on a supported version under extended support till September 2027 and enable your organization to begin migration.

With migration and upgrades uncoupled, a plan can be developed for when to upgrade to K2 5.9

Questions about your migration plans? Drop us a line at hello@caseitsolutions.com

The end of extended support for K2 blackpearl 4.7 is fast approaching. If you haven’t started planning your upgrade strategy, now is the time because December 31, 2025 will be here before you know it and you will be left on unsupported software. (see Support Lifecycles)

Many factors play into deciding exactly how to upgrade and this can make the whole process seem complex. This guide should help outline some ways to approach the effort.

IMPORTANT: Speaking of end of life, Visual Studio 2015 which is required for developing K2 blackpearl workflows reached end of life on October 14, 2025, so while you can still run the workflows the ability to develop K2 blackpearl workflows is already out of support. Another compelling reason for the upgrade to K2 5.9.

Step 1: Check the Versions, All of Them.

First, determine what version of K2 you are currently running. Refer to the Release Upgrade Compatibility Matrix to determine the upgrade path that must be followed to reach K2 5.9.

For example, if you are currently running K2 blackpearl 4.7, it will be necessary to upgrade to K2 5.7 before you can finally upgrade to 5.9.

After the upgrade path is determined, the next step is to refer to the Nintex K2 Product Compatibility matrix to cross reference the current Windows Server and SQL Server versions currently installed against what is supported by the intermediate and target versions of K2.

Using the 4.7 to 5.9 upgrade scenario as a real-world example from a client who is running Windows Server 2016, referring to the installation compatibility matrix we can see that both 4.7 and 5.9 are supported on Window Server 2016 so no operating system upgrades are required to do an in-place upgrade of K2.

In the chart above, you can see that you could get away without upgrading the Windows Server since all versions in your upgrade path are supported in 2016: 4.7 (current) to 5.7 (intermediate) to 5.9 (final).

IMPORTANT: From K2 blackpearl 4.7 to K2 Five there are changes to licensing details and software keys so that will need to be worked out ahead of time with your Nintex Customer Success Manager or Nintex Partner.

The same version verification is required for SQL Server versions. Keep in mind that there is also the added dimension of checking the SQL Server’s operating system’s requirements against any anticipated operating system upgrades.

Another dependency to not forget about in the planning process is SharePoint. There is a chart for those supported version as well.

As a reminder, the full support matrix can be found here: Nintex K2 Product Compatibility

Step 2: Assemble the Team

A K2 upgrade should not be completed in a vacuum. This is going to be a team effort. K2 solutions span an organization, and both depend on and impacted by other parts of the IT organization. The AD team, Networking (DNS) team, Security (if applicable), Infrastructure (hardware / virtualization), DBAs, and business stakeholders should all be either advised or involved in the planning process for the upgrade. The more complex the planned upgrades the greater the importance of active involvement and the need for them to be on standby when the day of the upgrade arrives.

Step 3: Decide What is Being Upgraded

The risk that I have seen come into play is attempting to do too much all at once.

I have seen teams that want to change out the SQL Server version, the OS version and move to new hardware in pretty much one go.

The infrastructure team may want to upgrade the SQL Server or Windows Server versions as part of the K2 upgrade. Window Server 2016 reaches extended support end of life on January 12, 2027 and pressure will me mounting to move onto a supported operating system.

I highly recommend treating the K2 upgrade and the underlying server software upgrades as two separate projects. The approach I found to be more manageable and help mitigate risk is to upgrade either K2 or OS versions, ensure stability then upgrade the rest.

Step 4: Choose How to Upgrade

We now know how to get to K2 5.9, we understand the supporting software version implications, and we want to start the upgrade. Where do we start and what do we mean exactly by “upgrade”?

It is this step where the environment setup you are working with does begin to strongly factor into the decision-making process. The goal is to get on a newer version but how do you want to get there?

This is the point where all the stakeholders need to come together and reach a consensus.

Is there going to be an attempt to do an in-place upgrade?

Is the plan to bring up brand new servers and just move the K2 database?

There is a lot to consider. I generally prefer to go with a bit more conservative approach as I like to reach clearly defined goals that leave behind an operational environment just in case something unexpected occurs.

The order of operations I prefer to follow is:

1. Stop the K2 Services on all nodes. Before the final backup, stop all the K2 services on each node in the farm. The K2 data needs to be persisted to the database and in a static state. If the K2 server is running, data could be changed after the database backup was completed leaving you with a stale backup.

2. Use an app_offline.htm file to gracefully take SmartForms offline. Using the built in functionality to .NET, an app_offline.htm file can be placed at the root of the SmartForms website to take the site offline. Placing the file in “<Installation Location>\K2\K2 SmartForms Runtime” will cause the contents of the file to be displayed instead of the normal website execution effectively taking the site offline.

   

   Mastery Tip: Using a app_offline.htm file is also a great approach to communicate with your user base to convey what is happening along with expected timelines instead of them being greeted by an uninformative error message.

3. Take Backups of VMs and Databases! I am sure it goes without saying, but it is important enough to reiterate.

4. Have a rollback plan. Most of my suggestions in this list come with an implied rollback plan but make sure yours is understood by the team.

5. Schedule an adequate maintenance window. This is not a project that should be planned to occur on a Friday after 5 and be ready for testing on Saturday morning. The more mature the K2 environment that greater the potential there could be a snag, especially when making a large jump from 4.7 to 5.7.

6. Plan to upgrade a lower environment first. If your organization has the standard Dev, QA and Prod setup or similar. I recommend upgrading one of the lower environments first. Generally, QA is similar enough to Production that it can be used to validate an upgrade plan. Also, leaving Development intact gives the K2 development team the ability to continue to support Production break fix issues while QA is being upgraded. This does break the typical change management pipeline, and I only suggest it for emergency Production support scenarios. Then upgrade Development leaving Production for last as that offers two opportunities to try to search for any potential roadblocks.

7. Make the least disruptive change first. For example, an in-place SQL Server upgrade is generally going to be less disruptive to the environment than moving to new hardware and at the end, the K2 environment should be left in a functional state, just with a newer version of SQL as the backend.

8. When moving a database to new hardware, move it before upgrade. I prefer moving databases before attempting a K2 upgrade as it allows for the validation of the database on the new server with a known environment before attempting an upgrade of K2.

   MASTERY TIP: If you must choose what to take extra care with during the upgrade, always choose the database. K2 server nodes are replaceable.

9. When upgrading K2 server hardware, upgrade K2 first. This may be a controversial take but hear me out. If there is a need to move the K2 servers to new hardware, I think upgrading K2 in place on current hardware allows for the validation of the upgrade. Then, the new hardware can be added to the K2 server farm as additional nodes. This approach keeps the whole farm functional, old nodes can be turned off to allow for validation of the new nodes, and the old nodes are still available as a fallback. Once everything is validated, remove the old nodes.

   MASTERY TIP: This approach can be used for single node farms assuming they were installed as farms. K2 should ALWAYS be installed as a farm. This setups up the farm with a DNS entry and not taking a dependency on the machine name which allows for maximum flexibility.
   

   BONUS: Existing K2 single server installs can be reconfigured to operate in farm mode by running the setup manager. You would just need to update any links or connection strings to the K2 server, plus if you are using Kerberos, update the SPNs of the K2 service account and potentially the application pool identities of the web-based components of K2. It depends on your overall installation details. If you are planning to do this, test in a lower environment first to work out the specifics.

10. Leave SharePoint for last. SharePoint can be a significant dependency for K2 solutions, but it isn’t critical for the operation of the K2 farm in a foundational way like Windows or SQL Server. New SharePoint farms can be stood up and site data migrated, but the final connection to K2 cannot occur till K2 upgrades are complete.

I realize that not all situations are created equal. The steps outlined are how I prefer to think through an upgrade. These are offered as better practice. Ultimately, it is up to your comfort levels and being pragmatic about your situation that should guide your choices.

Step 5: Uncertain? Call For Backup

If you are feeling nervous about an upgrade at this point, it’s natural. I’m a big proponent of erring on the side of caution when it comes to production systems, which why I may be a bit more verbose in my approach than necessary.

However, it should be noted that certain upgrades, while seemingly straightforward, may encounter unforeseen challenges for various reasons.

I have seen this issue primarily impact older, legacy K2 installations by causing database compatibility problems—particularly in environments that originally started as K2.NET 2003 installs, were later upgraded to K2 blackpearl (with multiple databases), and then further consolidated into a single K2 blackpearl database.

That much evolution over the years can leave database artifacts behind that can confuse the more modern upgrade installers.

Nintex Professional Services does offer two flavors of upgrade assistance, one for working hours and one outside of working hours, which can be helpful to have on standby for a production upgrade. I’d recommend reaching out to your Customer Success Manager to find out more.

The Best of Both Worlds

There is one guaranteed way to have a successful K2 upgrade, don’t.

If your organization is facing both a k2 blackpearl workflow migration to K2 Five design tooling along with upgrading K2 to version 5.9 then maybe not upgrading your existing farm is a consideration and simply standing up a new farm alongside the legacy farm is a viable path.

This is also an opportunity to take a critical look at existing workflows that are being migrated and determine what changes need to be made. Business needs evolve but did those workflows? Having parallel environments provide the organization with a much longer runway to have those conversations.

I have a client that is currently standing up a brand-new K2 5.9 farm on Windows Server 2025 after making the choice to leave the K2 blackpearl servers behind. They are taking a drain stop approach updating the K2 blackpearl workflows to K2 Five and deploying them to the new farm. Existing workflow instances will finish on the old farm and new instances will start on the new farm.

And that is a valid choice.

There is a lot of nuance and edge case scenarios to be considered that are more business operations and compliance questions than technical, but depending on your organization’s situation, it could potentially be the path of least resistance.

There are also some license implications but historically it has been my experience that Nintex has been working with customers to get over any of those hurdles and should be discussed with your Customer Success Manager or Nintex Partner.

If you are planning an upgrade and have questions, please feel free to drop me a line at hello@caseitsolutions.com.

Nintex Automation K2 is a powerful platform with many ways to customize it to meet your specific needs, but it can be challenging to know which options are available. This blog attempts to compile the most commonly used options in one place, along with a few honorable mentions for those edge cases we've all run into.

Many of the customization options listed here can be used for both K2 Cloud and K2 5.x customers, but not all. If the documentation mentions the file system or database updates, that customization won’t work for K2 Cloud.

If you want to get a deeper dive into customizations, subscribe to get updates on future posts.

The Background

K2 used to be positioned as a low-code platform, which, in my opinion, I always found a bit short-sighted. That messaging felt like it understated the software’s capabilities. Simplicity was essential to positioning K2 as something that wasn’t too complicated and accessible to the armies of citizen developers being cultivated. Still, I feel it missed the opportunity to attract the code-first crowd by highlighting what is possible.

I completely agree. K2 has always included a multitude of ways to extend the platform. The appealing aspect is that customization wasn’t required to get value out of K2, but it is a powerful tool to have in your kit.

The current ways to customize K2 come in a few different flavors, depending on how you define customization. There are ways to extend the platform’s core functionality, add integrations, and enhance forms’ capabilities or presentation. The platform has also made a couple of these more advanced customizations cloud-friendly by supporting JavaScript.

Customization Options: No Code

It feels like one of the biggest challenges to the adoption of K2 customizations was the lack of knowledge about the options available.

We will start this tour of those options by looking at what is available to those who do not want to write code.

Style Profiles

A style profile is a way to apply a consistent look and feel to a K2 form and reuse it throughout your solution. You can think of a Style profile simply as a visual designer for creating customized CSS that becomes a part of your solution as a deployable artifact. In its most basic form, a style profile requires no coding.

However, if you have a UI/UX wizard on your team, using a style profile will let them craft custom CSS and JavaScript to take things up a notch.

Nintex Gallery

The Nintex Gallery website offers several ready-made options for adding functionality to K2, including style profiles, controls, and service brokers. These have been written by either Nintex or the greater K2 community and partners. It is an excellent way to discover new features without writing code. The gallery highlights the art of the possible.

Custom Workflow Steps

This feature needs to receive more attention.

If you have always wished there was a SmartObject call you could just drag and drop onto the design canvas instead of having to configure the call each and every time you use it, then custom workflow steps are for you, but it is much more than that.

This customization point will really shine when paired with custom service brokers, enabling developers to bring significant new features to the K2 Workflow Designer.

The documentation is an excellent source to get started, and this feature falls into the “no code” category as long as you are using it in conjunction with existing Service Brokers or ones you may have downloaded from the Nintex Gallery.

As you expand into writing your own Service Brokers, you can add the finishing touch to that new integration with a custom step.

The one drawback of custom steps is that you are limited in your ability to customize the configuration panel and can only expose the same field types that the underlying SmartObject exposes, so plan your implementation carefully and consider how you want to handle any complexity.

Customization Options: Some Code

The next class of customization options is those that can be accomplished with a bit of code, such as HTML, CSS, some JavaScript, or maybe a line or two of C#.

Style Profiles (Advanced)

Style profiles get a mention here. While you can use style profiles without any code, the developer tab lets your UI guru attach custom CSS to enhance and go beyond the designer configuration approach. The documentation can be found here.

Email Notification Templates

Another one of those customizations that has fallen through the cracks is the ability to customize task notification emails. However, it is on the fringe for a reason. The email templates are installed by K2, so your changes could be overwritten during an upgrade. If you choose modify the template, be sure to keep a copy of your changes for future updates.

I couldn’t find a current help article, but there was a community post from a few years ago that covered the basics. You can find it here.

This customization will be global to the K2 server and needs to be configured on each node in a K2 server farm, since the templates are stored on each server node's file system.

The template files are located at “<Installation Folder>\K2\Host Server\Bin\Templates\Messages”.

If you think this is a feature you would like to see made a first-class part of the K2 customization story, give it an up vote on Nintex Ideas: Task Notifications Email Templates | Nintex Ideas

Custom Themes

Before style profiles, the only way a developer could refine SmartForms' appearance in a reusable manner was to create a custom theme. I feel that style profiles have superseded this feature, and using a custom theme requires database manipulation and manual deployment of supporting files to all the servers in a farm. If you find yourself with an edge case that isn’t covered by the style profiles, here is the documentation: Custom Themes.

Custom Inline Functions

Custom inline functions walk the line between “some code” and “more code,” as it depends on your design goals. Inline functions are intended to be basic; many can be implemented in just a few lines of code. The functions are meant for manipulating data inline, such as formatting a date, or a recent one I created that uses a regular expression to perform text replacement in a string (blog coming soon).

Read more about inline functions here: Custom Inline Functions.

Customization Options: More Code

These last two options are where you can bring a lot of new capabilities to the K2 platform and are THE extension point for a K2 developer to introduce custom code to address several scenarios.

For Nintex Automation K2 version 5.9, these options come in two flavors for on-premises installations: .NET and JavaScript. K2 Cloud only JavaScript is available.

Custom Controls

SmartForms can be extended with new form controls by either creating new .NET user controls or, as of 5.9, a web component. Check out Nintex Gallery for some examples of custom controls.

A little-known fact is that K2 uses Telerik controls for many of the UI controls in the platform today, and that DLL is on the file system and could be used to bring other controls to SmartForms that Nintex hasn’t implemented. There was a drive back in the day to add grid control to SmartForms using the Telerik grid view control. Maybe one of you out there is up for the challenge.

With the web components approach, the K2 team has provided a prototyping and test environment that allows the creation of new SmartForms controls independent of a K2 environment. This “Control Dojo” is one of the more compelling additions to the customization story in a long time. Check it out on GitHub and give Control Dojo a star.

Documentation:

• SmartForms Custom Controls (.NET)

• Custom controls in Management (Web Component)

Service Brokers

Service brokers are what provide the “smarts” in SmartObjects. They serve as integration points for other lines-of-business systems to move data, perform actions, or be created to expose bespoke functionality. The limit is your imagination.

Service brokers can be written as either a .NET DLL or written entirely in JavaScript. There is roughly 80% feature parity between the two methodologies, and any differences at this point are some particular edge cases.

Documentation:

• Custom Service Brokers (.NET)

• Introduction to the JavaScript Service Provider (JavaScript)

Customization Honorable Mentions

Finally, here are a few honorable mentions that I felt were worth including, as they have come up with past customers, and you should at least be aware that these options exist.

Custom User Manager: https://help.nintex.com/en-US/nintexautomation/devref/5.9/Content/Extend/Svr/UM-Creating.htm

Custom Log Provider: https://help.nintex.com/en-US/nintexautomation/devref/5.9/Content/Extend/Svr/Logging.htm

Custom Fonts: https://help.nintex.com/en-US/nintexautomation/devref/5.9/Content/Fonts/Custom-Fonts.htm

Custom Special Formats: https://help.nintex.com/en-US/nintexautomation/devref/5.9/Content/Formats/Formats.htm

Hope you find this helpful. Subscribe for future posts, as I am going to go into depth on several of these, especially custom controls and service brokers.

This blog post is intended to help guide the recruiter, the hiring manager, or the would-be candidate in determining whether the role is a match because nothing seems more abstract than a job description for a “K2 Developer”.

The demand for K2 developers is increasing. I keep reading posts online looking to fill roles. I have clients in a similar situation who have asked me, “Where do you find K2 developers?”

My honest answer is that in recent years, I have been growing my own. Identifying individuals whose background, experience, and interests would make them proficient K2 developers. Having worked with K2 for over 18 years, training hundreds of aspiring developers and enabling countless K2 partners, I’ve seen a pattern emerge.

What does that mean exactly? If you read the job descriptions, they vary wildly. Most of the time, they appear to be for a SharePoint, C#, Dynamics CRM, or other role to which K2 is an additional duty assigned.

The TLDR

Full Stack Developer + Solution Architect + Data Architect + Someone who enjoys calculating the Fibonacci sequence for fun.

Intrigued? Let me define who a K2 developer is and provide some much-needed context.

The Hard Skills

A K2 developer has the technical skills of a full-stack developer, the mind of a Solution Architect, and the analytical skills of a Data Architect, or some combination of the three. Having a portion of all three makes a candidate more successful.

For context, a K2 solution consists of SmartForms (UI), Workflow (business logic), and SmartObjects (data/integrations), which can be used as is, or there is room for customization where technical skills like HTML, CSS, JavaScript, C#, and SQL can be helpful, but are not required.

These skill sets are needed to build a robust and successful K2 solution. Just because they aren’t writing code doesn’t mean a K2 developer doesn’t need to understand how a solution is assembled and be able to envision the larger picture.

K2 as a platform encompasses UI, business logic, services, and data. A full-stack developer will have experience layering all these components together. The specific tool stack does not matter to K2; what matters more is the experience.

K2 solutions aren’t built in isolation. They are generally used to orchestrate larger, multisystem spanning processes. A K2 developer does not need to be an expert in those other systems, but they do need to understand their solution’s role, how that information must flow, and how those pieces all fit together.

In a K2 solution, data is vital. Being able to understand what data is needed and how it mutates during the life of the solution. Data is foundational. K2’s SmartObjects are the connecting thread that weaves through all levels of the application, and bad data design is a crack in that foundation.

Don’t panic. These traits are those of the ideal candidate, and we know unicorns are rare. If you must choose, go with a full-stack developer background. They will be better positioned to understand how to build in a K2 world and support that candidate with other members of your team who can help fill in the gaps.

However, if you choose to backfill with a shared solution and/or a data architect, be sure they complete K2 training to understand the platform’s constraints.

The more critical traits are those that cannot be taught.

The Soft Skills

What I have found to be more critical than technical skills are the personality traits. I can pretty much train anyone with the right level of technical background, but are they open to the challenge?

The question is less “what” is a K2 developer and more “who” is a K2 developer?

Someone inquisitive, enjoys a challenge, imaginative, methodical, and malleable.

Malleable may seem like a strange adjective to use, but it was the nicest I could come up with. There is an intrinsic openness that a candidate needs to succeed with K2. I have been in many enterprises, and there is always at least one developer who sits in the training, crosses their arms, and utters the age-old phrase, “I could write it faster in code.”

There is a whole philosophical discussion that could erupt around this sentiment, but a candidate with that sort of mentality won’t be successful.

To put it simply, the ideal candidate needs to be open to working with K2, accept the constraints, and find joy in exploring all the possibilities.

Working with K2 can be fun. I personally enjoy the game of it. I long ago accepted the challenge of working within the constraints of the K2 platform. I look for that same openness to the challenge in others.

The ideal candidate should also be methodical. K2 solutions require an individual who is organized and detail-oriented to create orderly solutions and follow the flow of logic, someone who understands that there is a happy path and an exception path, where there is an if, there is an implied else. A very analytical mind that enjoys the challenge of solving for the unknown, i.e., the Fibonacci sequence. I find that former support engineers generally have the potential to make strong K2 developers.

This not only helps them develop solid solutions but also aids debugging when trying to understand why an empty row is being inserted into the database on file add. There is a story here, maybe I’ll share it sometime if I write about troubleshooting.

Finally, just going through the K2 training alone does not make a K2 developer, just as reading a recipe does not make a Michelin-rated chef. It is the first step on a journey of discovery. Much like Sudoku. Moments to learn, a lifetime to master. Maybe not a lifetime, but there is some work on the part of the would-be developer to go from the knowledge to practical application: the science vs. the art.

I hope this helps you better define who you are looking for in your next hire. I always welcome questions. Please feel free to leave a comment or drop me a line at info@caseitsolutions.com.

Christmas came just a bit early with the release of Nintex Automation K2 (K2) version 5.9! This is more than just a maintenance release; it includes some exciting new features.

Let’s start with the platform enhancements. K2 continues to build on the features introduced in 5.8.1.

JavaScript Service Provider (JSSP) – This new service broker lets you move beyond writing new integrations for the K2 data layer in .NET code and into JavaScript. Debuted in K2 Cloud, introduced to on-prem customers with 5.8.1, it now comes to 5.9 as a long-term support release, with added support for Smart Object file properties.

Rest Broker, open API v3 support. Another 5.8.1 feature that has been enhanced with the support for HTTP response codes, enabling better management scenarios for when a web service call doesn’t go the way you planned.

OData v4 Service Broker gets a feature bump with support for nested entities. This was introduced to facilitate better integration with Dynamics 365 Business Center.

SharePoint Broker has a new method that is automatically added to your discovered SharePoint artifacts, enabling you to “Remove All Permissions.” This feature essentially allows you to reset the permission on a List, for example, and then set more fine-grained control as your requirements need. It is excellent for compliance scenarios when the permissions need to change over the life of a workflow.

On the topic of SharePoint, with this release, Nintex has made additional investments in the “Nintex for SharePoint Workflow” importer API. If you attended our K2 Master’s workshop, K2 Product Manager, Codi Kaji, shared a demo of the import API, but the UI wasn’t quite ready. It is now here with 5.9.

Also, if you think we should do another workshop, drop a comment below. 👇

Other platform improvements include:

• Optimized SQL Queries for Identity Provider Framework, making it more performant for large organizations.

• Add Hyperlinks to Categories in Designer. Allowing you to make a ready reference for something like a related Jira board or Nintex Process Manager solution.

• Environment Report. The report that used to be run via a SQL script to understand how your K2 environment is being used can now be launched from K2 Management. This provides insights into the number of users, volume of workflows run, etc.

• Updated JavaScript and CSS Support.

Speaking of JavaScript and CSS Support, the most exciting feature in 5.9 is the introduction of the new SmartForms Web Component controls! I have always loved the idea of extending SmartForms with custom controls. I’ll admit it wasn’t always the easiest to do, but it is a powerful, underused capability of K2.

“You don’t have the form control you need for a particular use case?” Make your own!

Web Components Controls continue in the tradition of extensibility and reusability that has been central to the K2 ethos.

K2 is releasing a series of new controls on the Nintex Gallery website. I recommend checking them out. The three controls mentioned during today’s webinar were the CAPTCHA, the Arabic Calendar, and the long-awaited Drag-and-Drop file control.

I plan to write a whole series on creating custom controls in both the traditional .NET user control-based approach and the new web components model. I also have some thoughts on how those could be leveraged together. Subscribe to get notified when that series drops.

The one thing that wasn’t mentioned in the webinar that I have had the chance to preview is the new Control Dojo. You will be able to get your control-creation mojo going with this new control-development tool from the K2 product team.

Available at k2workflow/Control-Dojo, the project is described as “A modern web-based development environment for Nintex K2 custom controls with both debugging and control generation capabilities.” The dojo addresses some of the challenges with developing custom controls for SmartForms by providing a standalone prototyping and test environment independent of a K2 environment.

It is as easy as cloning the GitHub repo, typing npm install then npm run dev:full.

Some honorable mentions discussed in the release webinar were:

• The introduction of the SCIM API, which lays the foundation for Okta, Ping, and Keycloak identity support in K2. I remember discussing SCIM and K2 with the Microsoft Identity team back in 2018, so I’m glad to see it finally making its way into the product.

• SmartForms Runtime Accessibility. The runtime side of K2 SmartForms is now Web Content Accessibility Guidelines 2.1 Level AA complaint. There was a good demo of the feature during the webinar.

Check out the full Release Notes at Nintex.com

There is a common theme I have observed with many solution-oriented platforms in the last several years. Platforms and their partners offer a myriad of prepackaged solutions or bespoke methodologies promising to enable customers to get their first solution live faster.

For the purposes of this post, I will use the term ‘accelerator’ to encompass both pre-packaged solutions and bespoke methodologies.

When businesses are spending precious capital on new platforms, it is entirely understandable that they want to start seeing a return on that investment sooner rather than later.

The increased pressure of the impending deprecation of the SharePoint workflow engine has teams scrambling for an easy button as they look to migrate those legacy solutions to new platforms.

Nintex Automation K2, for example, offers a series of prepackaged solutions called Smart Starters. In contrast, many Nintex partners provide their own tools or methodologies to help them stand out in a crowded field of implementors, each promising faster time-to-first process-live.

And some of these are great approaches, but what I feel needs to be said is to proceed with caution when adopting a framework or methodology.

Think back to grammar school and early math classes. In the same way that you were discouraged from using a calculator until you could prove you understood addition, you should avoid leaning on an accelerator for help until you are familiar with the platforms.

An accelerator should not be used in place of understanding how to use a platform effectively.

I have recently said in class that K2 is not highly opinionated regarding how it is implemented when crafting a solution. There are a few solid rules that you should never break, like using the API to make changes to a running workflow from within that same workflow, thus creating the digital equivalent of a bootstrap paradox, or, in DBA terms, database locks.

That is both the joy and the challenge of working with K2.

There are multiple ways to achieve various goals in the platform. It is a primary reason that when speaking with seasoned K2 consultants, their first words in response to many questions will most likely begin with, “It depends.”

It isn’t deflection; it is just an honest response from a wise consultant who knows there are options for addressing business requirements, and that your choices should be driven by an understanding of the fuller picture of what is trying to be accomplished.

The myriads of options can present a challenge to a new K2 developer, and it is that glut of choice which drives the appetite for accelerators.

Used in the proper context, accelerators can be an immense help in providing direction, but they are not without risk.

Accelerators are generally meant to obscure complexity in exchange for velocity. Build new solutions faster without going too deep. The risk here is that K2 is already obfuscating complexity in exchange for visual design tooling and reusability. Many times, accelerators try to obfuscate the perceived complexity of K2. What do you get when you obfuscate complexity that is obfuscating complexity? New complexity!

Am I suggesting you don’t use accelerators? Absolutely not. They can be great tools, but they aren’t meant to be a substitute for knowing how to leverage the software’s features.

Methodologies or “better” practices can serve as excellent starting points and guides for managing your solutions on the K2 platform. The K2 Center of Excellence materials on the K2 Community website are a good resource for approaches that can help your foray into K2 development go smoothly. Just don’t feel you are obligated to craft your solutions exactly as shown in those documents. Find what works for you and your organization.

When using something like a Smart Starter, for example, a K2 developer is going to be beholden to the K2 product team’s opinion on how to build a solution. K2 uses its own product to make K2, so its understanding of how to build with K2 is constantly evolving.

A K2 developer needs to know how K2 solutions are put together so that they can maintain a prepackaged solution or customize it to meet business-specific requirements.

My recommendation is to take the time to build your first solution from scratch when getting started with K2. Learn how the parts fit together, how they behave, and how you troubleshoot problems. Use accelerators as a cheat code to gain inspiration for building your solution, but make it yourself. The hands-on experience will serve you well as you move into more complex solutions, or if you decide to adopt an accelerator, you will be in a much better position to both customize and maintain your project.

What do you think? I would love to hear your thoughts on different approaches for getting to your first process live.

Three sessions were not a lot of time to go over a laundry list of topics, so the hope is that I am going to be able to dive a bit deeper and focus on many topics that I did not have the opportunity to go into as much depth as I would have liked.

I’d be lying if I said there was going to be any sort of schedule to these posts. Most of it will be driven by the intersection of available time and inspiration.

So many more topics to dig deeper into like custom smart forms controls, service brokers and other customization topics that do not get as much attention as they deserve as I feel it is beneficial to know exactly how far you can push the platform in a supported way.

Like Codi mentioned in the class, K2 isn’t low code so much as it is more code, meaning that while you can do a lot without writing a single line of code, when you do want to write code it is with more purpose and more reusability.

Customizations are my personal favorite, and other topics will be touched on. Please feel free to drop me a line at info@caseitsolutions.com if you have any topic suggestions.

Subscribe now