All ideas

Store procedure is a very important component when client decided to store their data in SQL Server. Store procedure could easily build the data schema that need to display in Nintex Apps.

Take data within an action set and store it into a collection variable. This is handy when kicking off component workflows. collections is the primary way NAC accepts rows of data to be used in repeating sections of forms.

Have an action where you can feed a JSON string. Define what parameters to parse out and store values for in variables within an action set. This will be handy for AI use cases where JSON is returned as a string within a variable. Currently, the R...

When building Action Flows, we can drag and drop actions. It would be nice to be able to copy & paste actions, then drag them where we want them.

It would be nice if we could make the Skuid.debug console command made into a component that we could put directly into a page. Taking the code out of it and making it low code/no code.

More robust Javascript documentation, including examples and real-world use cases

In Nintex DocGen, can the application dynamically calculate the total number of pages produced when the package is generated and set that value into a field tag available for templates?

When you have a complex app and multiple components and styles, it would be helpful to have a way to see For each component, which pages it's used on For each style variant, which pages it's used on

More robust Formula documentation for Ui-Only formula fields, including examples and real-world use cases

There are no elegant solutions currently for comparing versions of app pages when deploying between environments