Transaction Types – the Core of Processes in Flowis

Firstly, let’s have a look at the difference between Transaction Type and Transaction. We can say Transaction Type is a process (e.g. the process of processing invoices) and Transaction is a particular item in this process (particular invoice).

Creating a new Transaction Type is inevitable while designing the process of creating and using a new Transaction. Everything starts here. In Transaction Type you define main things like Transaction’s name (e.g. Invoice), if it is active, all data types which will be used in the Transaction (e.g. invoice number, date, purchase order, etc.). and other definitions.

General setup

Transaction type group – each Transaction Type must be classified under a certain Transaction Type Group. Transaction Type Group must be created before a new Transaction Type is set up.
Name – create a name for your Transaction, e.g. Invoice.
Description – description is used for internal information. It is not displayed to Users and serves only for admin notes.
Public name (ruby eval) – entering a Ruby code can change the display name of the Transaction type. By default, ID is shown. Contact your IT administrator to add anything to this section.
Allowed invoice/transaction file extensions – each Transaction can contain a transaction file. Here you can restrict which formats can be used as transaction files – fill it in like this: “.pdf, .docx, .jpg” etc.
Delegatable? – if checked, when user setups delegations, Transactions under this type will be available. You can restrict which Transactions cannot be accessed by delegatee and will need to wait for main User to return.
Active? – the Transaction will not be displayed to the User nor will it be possible to create it unless you activate it. However, you can create everything else you need (e.g. Create Permissions, Workflows, etc.) although the Transaction Type is not active yet.

Data types definition

Data types represent the fields in the Transaction and what kind of value they can have. It does not matter if the information is present since the creation of the Transaction or it is inserted later, it has to be defined here – if it is text, number, date, dropdown of data, etc.

You can add new data type with the + button on the right side of the screen. To set it up, you need to fill in:

• Field name – technical name of the field that is used on the backend and when working with this value. It should be lower-cased under-scored full name of the field, e.g. “invoice_number” or “customer_reference_code”. In some cases there are other requirements, like associations to other tables must end with “_id”, e.g. “service_id” or “customer_material_code_id”. The lock function in this field will take into account all these requirements and create the Field name based on the Public name. The same Field name must have the same configuration across all Transaction Types. This is to ensure consistency when searching without specific Transaction Type or when downloading to Excel. If the field is a “text” in one Transaction Type, it must be a “text” in all Transaction Types.
• Public name – visible field name shown to the Users. It cannot contain dash “-” as that is used as a special separator when joining multiple columns into Excel downloads. You can also add Alternative public name – it can contain further explanations of what should be filled in the field (to help Users understand).
• Data type – type of the field – what kind of value it can have. See our article about Data types for more information.
• Options – additional options based on the selected data type.

Additional settings of the Data types accessed through cogwheel sign:

• Snapshot? – snapshot flags the attributes which we want to “enseal” on the Transaction in specific time. Attributes then can be renewed later if needed. The ensealing is done manually by a code, so please, contact your IT administrator.
• Info – information for User which can better explain what is expected to be filled in the field – tooltip, alert, or help

• Default – Ruby code to setup a default value when the form is loaded or when the transaction under this Transaction Type is initialized anywhere in the tool. Needs to be set up by your IT administrator.
• Parse data entry to value – Ruby code to setup custom mapping logic for each field separately. Needs to be set up by your IT administrator.

Additional settings

On-change dependencies – this section can automate the behaviour of selected fields in two different ways – it can either update the field’s value if the value in another field changes (e.g. it can calculate the total amount from given NET amount and TAX amount) or it can show a warning that will appear once an invalid value is typed in (e.g. if the invoice number contains spaces or other non-supported characters). However, this setup requires coding, so please, contact your IT administrator if you want to add anything there.

Model callbacks – model callbacks can perform an action after or before saving the transaction, such as validate the values in fields, fill in the values in any of the Definitions and so on. This setup also requires coding, so please, contact your IT admin if you want to add anything there.

Design of transaction detail and list:

• File template – if you have a File Template set up, select it here so it can be used to generate files based on the fields filled in on a Transaction.
• Show icon “has action file” on transactions list? – icon of an attachment will be shown in the Transactions list, if there was any action file attached.
• Show icon “is last comment” on transactions list? – icon of a comment will be shown in the Transactions list, if there was a comment in the last action.
• Order of “Action required” options – if the User has more options of what to do with the Transaction, the order of these options is set up there.
• Show workflow progress in transaction detail? – if the Statuses belong to hierarchized Status Groups, you can display a diagram of the progress of a Transaction in the Transaction’s detail. Learn more about this topic in our Status Groups article
• Status groups – which Status Groups should be included in the workflow progress diagram. They are sorted based on the order in Status Groups table. Only Parent Status Groups are available here – their children will be shown in the diagram automatically.
• Status group levels – if the Transaction’s flow is complex and used Status Groups have their Parent Status Groups set up (so the hierarchy of Status Groups has several levels), you can insert a name for each of the levels.