Differences between workflow and namespace

The primary purpose of Namespaces is to represent sets of data that do not require flow. However, most business areas can be presented either in a static form or in a flow form.

There are also areas that can be presented in both forms. Finally, there are also those where the flow is limited to one activity of the process – in this case, a static presentation is also a much better solution.

A great example of the duality of business situations of this type is the issue of incoming (cost) invoices. In Dew-X, you can implement this as either a document workflow, a Namespace, or both. In the first situation, we create a process definition (e.g. cost invoices), which may include activities such as registration, substantive description, approvals or accounting verification. After the cost invoice is received, it is loaded into the workflow, creating an instance, and follows its path as defined.

In the second case, we create a Namespace called “Incoming invoices”. It has no flow, but we can use fields such as status or payment status to define where it is now, and to include information on the acceptance, validity or compliance of the document in the comments.

In the third case, the invoice flow takes place in the processes section, and the namespace linked via integration is used to manage and search it after the process is completed.

Namespaces are better suited where permissions and record navigation are more important.

The differences between static representation (Namespaces) and workflow (processes) and recommendations for using a specific one are included below:

• Permissions – excluding administrators and people with the Search role, a user can see a given process instance only if he/she participated in it or was CC’d. However, he sees all processes within the organization. In the case of Namespaces, the user will see a given Namespace if it belongs to authorized users. In terms of records in a given Namespace, he can see those with default visibility and those to which he has been personally added. Where there is extensive specificity of permissions, it is better to use namespaces.
• Navigation – within the processes, the user can see the instances that he has to perform, those in which he participated (both in progress and completed) and those that have been CC’d to him. Processes are represented as cards containing a maximum of three pieces of data (highlighted variables). After entering and exiting a given card, it is highlighted on the list, unless it has already been forwarded by us or has ended. In the case of Namespaces, individual records are presented as rows in a table described with metadata and any number of highlighted variables.
  Thanks to the large amount of data and tabular layout, Namespaces allow you to obtain more information without going into details. However, namespaces are static – so their state does not change except when a given record is deleted or the user loses permissions to it. For this reason, namespaces are less suitable for business situations where it is important to quickly and intuitively obtain information about the current progress or location of a given record. The record is navigated on the data and history tab. In the first tab we see the current state of data, and in the history tab we see how they have changed. In the case of a process in progress, by default we go to the tab related to the current activity of the process, and the data status from previous activity is represented in the form of tabs – one per activity.
• Search – Namespaces allow you to precisely search table values using multiple variables at once. However, the nature of the search is always LIKE %%, which means “Similar to” regardless of whether the value in the column is text, number or date. The exception are two system dates that allow you to search by date range. The AND operator, which connects individual filters, is the connector for individual queries. The more filters completed, the more precise the results become. The main search engine of the system does not allow searching by values – selecting “Namespaces” from the options of this search engine and indicating a specific one will take the user to its view. Searching in processes takes place in one of three contexts (to do, in progress, completed) and allows you to search a set using one value contained in up to three distinguished variables. However, processes allow their contents to be searched using the system’s main search engine. If we want detailed searches from large sets, Namespaces will be better. Where the search is most often done by a specific parameter (e.g. process ID, project name), processes will work better
• Responsibility – processes, by definition, allow for easy determination of the person responsible for a given process instance and the current status. A given instance may be held by one person or by many people – individually designated or belonging to a group. In the latter case, the action of only one, most or all of them may be needed to advance the process. However, the processes are equipped with a retry mechanism with an escalation option. When creating a process, we can determine how long a given activity should take by default and how many times this time pool can be refreshed before the process ends or rolls back. In the case of processes, responsibility is very clear to determine, and streamlining the process is much easier. In the case of Namespaces, no one is personally responsible for a given record, except in situations where permissions are granted to one or a narrow group of people. Due to its static nature, there are no issues of escalation or deadlines. You can support this process by configuring appropriate fields (e.g. date of next contact, responsible person), but they do not generate any action in the system and require the supervisor to review the progress in a non-automated way.
• Data recording – processes, apart from the values in Data sheets, can also save values per activity. This means that a variable with the same name (e.g. decision) occurring at several activities will have as many values as there were activities. Even if such a variable is to be used as a distinguished variable in the process, the creator must indicate from which activity it will come. In the case of Namespaces, this variable will be versioned. Each change is saved in the history, but on the data tab we can only see the last state of this variable. Both approaches have their advantages and disadvantages – we recommend using the process approach when it is extremely important to specify the source of data – it is similar to other people putting the same stamp on the document. The Namespaces approach is better when current variable values are given more weight than their historical equivalents. Of course, such a dilemma should only be considered when we want to store frequently changed information under the same name. Otherwise, both approaches will be equally good.

You can read more about Namespaces here