Skip to main content

Hi there,


A question pertaining to "process" and their "data"
so the relationship between the process and the data. Subsequently is it
better to design data for processes:


1. Embedded in the K2 process through the use of data fields and/or smart objects.


2.
Or, in a data store (db) like in the source application and use a field
in the process (like folio) to retrieve the data specific for the
process when loading the forms and etc...


The nature of my
question is to adopt best practices whilst full fulling business
requirements. Storing the data in the source application db makes
reporting that much easier AND more importantly makes the process
light-weight as only the bare minimum fields are store with the process.


Im interested to hear your guys feedback.


Regards,


Justin

Bump

Hi Justin,


Best practice is to keep your data externalised in a custom DB or a SmartBox database, this way the process does not get bloated and the data is readily reportable. As you say just keep a key field in the process to look up the data when you need it.


That said there are times when processes are very simple and the reporting side of things is not overly important for the project, i.e simple document approval. In this case externalising 4-5 data fields to a db may be overkill, so keep them in process fields, dev fast and get value for the business quick.


hth

100% thanks Murphy.



Normal
0




false
false
false

EN-US
X-NONE
X-NONE













MicrosoftInternetExplorer4


































































































































































It is a best practice to externalize the data and definitely
yes if any attachments are involved. K2 maintains log of the data which bloats
up eventually. Again all these decisions are taken based on the resources you
have and time line and gravity of the project.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings