Instant Estimate +44(0)1908738254
YOUR EXPERT RPA PARTNER

Team up with our RPA strategy and tech specialists for maximum automation impact

Find out more
Harness the power of UiPath in your business.
WATCH NOW

Save money and spend more time on priority work.

Book consultation
READY, SET, AUTOMATE

Let's choose, design and deploy a process automation solution for your business.

Find out more
TRANSFORM YOUR BUSINESS

Let's analyse your business to discover opportunities for innovation and automation.

Find out more

Begin your business transformation journey

Book consultation
AUTOMATE EVERY FUNCTION

Automate where it matters most. Scale to solve challenges in every area

Find out more
GIVE EVERY TEAM THE TOOLS FOR SUCCESS

Equip people with user-friendly solutions that save time and make work easier

Find out more

Which business problem
can we solve first?

Book consultation
21 July 2014

The use of K2 data fields

K2 developers always ask themselves the question when to use K2 data fields, or what is the correct best practice when using data fields.

It is important to realise that K2 data fields are global to a K2 process, and like any global variable, it’s existence and usage should be carefully considered.  The decision should generally not be a difficulty and time consuming one to make, but it can impact the future maintainability of a K2 process.

K2 Automated Testing Software

BenchQA allows full test automation of K2, including fully automated K2 SmartForms and K2 Workflow testing. It promotes test driven development for K2 and ensures continued quality assurance for K2 solutions. Easily apply changes to test cases to accommodate changes to K2 apps and ensure all apps are regression tested to avoid defects and assure continuous quality.

 

Free K2 Five Upgrade Review

 
The first question you need to ask yourself relates to the scope of the K2 data field.
1. K2 process wide, and tied to the process instance’s version
2.  K2 activity wide
3.  System wide, tied to no version of a K2 process or a K2 activity, but a reference is required in K2.

If there is a requirement to have access to the field throughout the K2 process and the value generally stays static and is used in pure K2 workflow routing decision making, a global K2 process variable can be defined.

If there is no global scope requirement for a K2 data field and it is merely used in context with a K2 activity and are generally static, it can be defined at the K2 activity level.

If the value is extremely dynamic, its version not tied to the lifetime of a K2 process instance and it could in future be used in conjunction with many additional data fields (for example to make routing workflow decisions or for K2 rule evaluation), the use of a non-K2 data field approach is sensible.  The implementation of this pattern still require a single K2 data field to be defined, but this merely acts as a reference to a system business object.  This object is typically rapped around a K2 SmartObject and additional future properties can simply be added and referenced in the K2 workflow.

Need further technical advice or support?