You can create user-defined forms and process documents automatically.
With the graphical form editor you can create new forms with drag-and-drop and extend objects with new properties without programming knowledge.
Either you can add a form to an existing object (shown in the properties of the object) or you can create basic objects based on a form.
Note: You can only create, edit and release forms and categories if you are authorized in the Edit Forms and Categories organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of forms and categories.
Form Fields
You can use the following form fields on your form:
Types
You can define the following types for input fields and item lists:
Note: If the form has already been released, the type of a field can only be changed to compatible types (e.g. from string to hyperlink or password).
Additional Settings
Depending on the type, you can make further settings for form fields. In general, you can specify:
“General” tab
“Advanced” tab
“Display” tab
Trace output
When you use expressions for calculation or validation, it can sometimes be difficult to identify errors in the expressions. To simplify analysis, you can write trace output to the web browser console. To do this, you must go to the context menu of the Teamroom where the form is used, choose “Tools” > “Activate Trace Outputs” and allow trace output.
Call in expressions:
Output:
The output is a JSON data record.
Forms can be used in the context in which they are defined or referenced. To make forms generally available for Teamrooms (but not for app rooms), use a form and category collection in “Customizing”. Otherwise, forms can be stored in app configurations (“Forms and Categories” widget), in app rooms (“Templates and Presettings” action > “Forms and Categories” widget) or in Teamrooms (“Templates and Presettings” action > “Forms and Categories” widget).
To create a form, proceed as follows:
Note:
Backward Linking
For an input field or an item list of type “Object” (type of content: forms), a backward linking with another input field or item list of type “Object” can be defined. In the case of backward linking, the other object is automatically referenced in the object entered in the field.
Note: The field or fields for backward linking can be located either on one form or on two forms.
To define a backward linking with only one form involved, proceed as follows:
To define a backward linking with two forms involved, proceed as follows:
Example
The following example shows in particular the possibility of using expressions in forms. The amount of each installment is to be calculated based on a total amount and a payment frequency.
Create a form (“Object With User Data” base class) with following three properties:
To calculate the installment dynamically, you must define expressions for the fields:
Calculating Value |
---|
Currency @installment = cooobj.totalpayment; if (@installment.currvalue) { |
You can also make the following settings in the properties of a form.
“Advanced” tab
“Retention” tab
You can specify whether objects based on the form are retention worthy. This tab displays the Category (Draft) retention properties. When the form is published, the settings are applied to the Category (Published).
“Translations” tab
For the languages available in the Fabasoft Cloud, you can provide translations for the names and context-sensitive help. For each multilingual name of the form, you will find a corresponding entry.
In the form's properties on the “Form” tab, you will find the corresponding templates. You can use the templates to create objects directly based on the form. If you want to prevent this, choose Suppress Template Creation and publish the form again.
In the form's properties on the “Form” tab, you will find the corresponding Category (Published).
The category can be used for the following use cases:
Note: The settings of the Category (Draft) are applied to the Category (Published) when the form is published.
Adding a Form to an Object
Not only basic objects that are based on a form can be created but it is also possible to extend existing objects with a form. This is particularly useful for templates.
To add a form to an object, proceed as follows:
The form is displayed in the properties of the object. When you define the object as a template, the form is available with each newly created object that is based on the template.
Further Use Cases
A description of the further use cases of a form category can be found in chapter “Categories”.
Forms can also be used to define compound types, which in turn can be used in other forms as types for input fields or element lists.
Defining a Compound Type
To define a compound type, proceed as follows:
Note:
Using a Compound Type
To use the compound type, proceed as follows:
Categories can be assigned to objects (“General” tab) and thus influence the behavior of the objects.
Categories can be used for the following use cases:
User-defined categories can be used in the context in which they are defined or referenced. To make categories generally available for Teamrooms (but not for app rooms), use a form and category collection in “Customizing”. Otherwise, categories can be stored in app configurations (“Forms and Categories” widget), in app rooms (“Templates and Presettings” action > “Forms and Categories” widget) or in Teamrooms (“Templates and Presettings” action > “Forms and Categories” widget).
The “Change Assignment” context menu command can be used to change the context of the category.
Note: You can only create, edit and release forms and categories if you are authorized in the Edit Forms and Categories organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of forms and categories.
Defining the Registration Behavior
By default, the “Register as” context menu command provides all possible registration targets. If the registration target is well-known, it can be restricted to improve the usability (Incoming Category for Registration field).
Defining Default Follow-Ups
To receive a reminder at a specific time, follow-ups can be used (Default Follow-Ups field). You can find more information on follow-ups in chapter “Follow-Ups”.
Defining the Applicability
Not every category make sense for every object class. Thus, the object classes for which the categories are allowed can be restricted (Applicable for field). In addition, if you want to use special base dates for follow-ups or retention periods a restriction to the object classes that provide the desired properties is needed.
If you want to restrict a BPMN process to a category and use activities that are allowed only for a certain object class, you can define the category accordingly (only the corresponding object class must be entered).
Defining Retention Worthiness
Compliance rules may enforce that objects must not be deleted for a defined time period (“Retention” tab).
In the properties of the category, on the “Retention” tab you can define whether objects with this category are retention worthy. In addition, define a Retention Period and a Base Date for the Beginning of the Retention Period. The calculation of the concrete retention period is carried out via a background task, which must be defined on the “Background Tasks” tab.
Note: Alternatively, you can also use the “Create/Edit Background Task” button on the “Retention” tab.
In the background task, select the “Determine Retention Period Based on the Category” action. In addition, determine the date when the background task should run. In general, it makes sense to use the Base Date for the Beginning of the Retention Period as Base Date for the time interval and, for example, “Immediately” as time interval.
For disposal, you can define another background task in the category. In general, it makes sense to define the Retention Period as base date for the execution of the task. As action, you can either select “Delete Automatically” or “Start Process”. If you want to start a process, you must also specify the process. In the process, a task with the activity “Retention Period Exceeded” should be defined.
When the background task is executed, the process is started and can be processed by the defined users in the worklist. The “Retention Period Exceeded” activity provides the steps “Delete”, “Extend Retention Period” and “Accept”.
Defining Background Tasks
Background tasks allow you to perform actions at a specific time (“Background Tasks” tab).
More information can be found in chapter “Background Tasks”.
Defining Permissions
In general, the defined team can access the Teamroom and its contents. Access to individual objects can also be granted via a category (“Permissions” tab).
Note: In order that the access rights granted via categories are evaluated, the entry “Extended by category” or “Extended by category and workflow” must be selected in the Access Protection field of the Teamroom.
For categories, background tasks can be stored that execute an action at a definable point in time.
Actions
Possible actions (extendable by apps):
Note: The background tasks of objects are displayed on the “Background Tasks” tab. Whether background tasks that have already been processed are displayed depends on the action. You can override the default setting of the action using the Remove Processed Entries From the List of Background Tasks field.
Point in Time
The action can be executed at an explicit time or at a time based on a base date. Optionally, the execution date can be redefined if the base date is changed.
Repetition
It is also possible to repeat background tasks. The following cases can be distinguished.
Explicit date or date is not recalculated when the base date is changed
You can define a repetition rule that is applied starting with the execution time.
Date is recalculated when the base date is changed
The background task is rescheduled after the selected action is executed and the base date is changed. Only Repeat Until can be defined as a repetition rule.
Suspend Background Task When Deleting
You can define whether the background task is automatically suspended when the affected object is deleted or canceled and again activated when the object is restored.
In an inbox, rules for the processing of incoming objects can be defined. A rule consists of conditions and actions.
You can create an inbox in your personal folder (background context menu > “New” > “Inbox”). As for Teamrooms, you can also set a team for inboxes to define the access rights.
Note: You can only create and edit inbox rules if you are authorized in the Manage Inbox Rules organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of inbox rules.
To define rules for an inbox, proceed as follows:
For an object placed in the inbox, the rules are checked according to the order. If all conditions of a rule apply to an incoming object or no condition has been defined, the defined actions are executed on the object. Only the first applicable rule is executed.
Note:
The Fabasoft Cloud in conjunction with Mindbreeze InSpire allows you to automatically classify documents and extract metadata. Especially when interacting with custom forms, you have a powerful concept for the incoming classification of documents for your particular application.
The following steps explain the basic operation:
The classification requires a Mindbreeze InSpire service, which can be configured by the organization administrator (for more information, see the administration help).
The classification value calculated by Mindbreeze InSpire is used to determine a category based on the Import ID of the category. The following processing can be defined via the category:
Categories are used in the context of different apps and can be created or managed there (e.g. custom forms).
User-defined forms (see chapter “Forms”) can be taken into account during classification. The corresponding Category (Published) is displayed in the properties of the form. Define in the properties of the category classification value as Import ID, which is returned by Mindbreeze InSpire for the corresponding type of documents. This way the registration is based on the form.
The metadata extracted during classifying is applied to the corresponding fields when registering.
Note: If the programming names of the user-defined fields do not match the Mindbreeze InSpire keys, your organization administrator must enter the corresponding mapping in the Mindbreeze InSpire service.
Documents can be classified automatically via the inbox. To do so, you can define a rule that performs the “Classify With Mindbreeze InSpire” action (see also chapter “Inbox”).
When using the “Register” activity, documents can be classified and registered via the workflow. You can start an ad-hoc process with the prescribed activity “Register”. In a predefined BPMN process, the activity can also be used (the usability has to be restricted to documents).
The following steps can be performed via the activity. Only appropriate work steps are offered in the respective context.
When you register a document, you can capture metadata of the document in a split view (on the left the metadata, on the right the document). If necessary, the document is also assigned (e.g. to a file).
Register (generic)
The generic registration is available if no category could be determined by the classification. In this case, you can capture metadata in a split view.
Register as (incoming category)
An incoming category determines the registration and assignment of the document. The incoming category can be assigned directly to a document or to a category that is assigned to a document. If no category is assigned to a document, the incoming categories of the licensed apps are also considered.
Register as (form)
When a form category is assigned to a document, the user-defined metadata can also be entered in a split view.
The form inbox allows you to capture data using an HTML form and store it in the Fabasoft Cloud. You may also use an Inbox room as an alternative to a “Form Inbox”.
To create a form inbox and receive the identification of the form inbox, proceed as follows:
As an alternative to a “Form-Inbox” you can also create an “Inbox” room. In that case you have to use the Fabasoft Cloud ID as identifier for this Inbox room.
To define a corresponding HTML form on a page of your web site, proceed as follows:
You can specify the following fields in the HTML form (unless otherwise specified, the fields are optional):
Field in HTML Form | Description |
---|---|
objectclass | Required field (as long as objecttemplate is not used): Defines the Fabasoft Cloud ID or full reference of the object class from which an instance is to be created in the form inbox after the HTML form is transferred. |
objecttemplate | Only evaluated if objectclass does not exist. Defines the Fabasoft Cloud ID of an object that is to be copied after submitting the HTML form. The user "Form Poster Fabasoft Cloud" must have the right to read and copy this object (and dependent objects). Moreover the template must belong to the same cloud organization as the form inbox object. A template must be either a Document (ContentObject), an Object With Object List (CompoundObject) or a Basic Object (BasicObject). |
inbox | Required field: Defines the ID of the form inbox. Alternatively, the Fabasoft Cloud ID of the form inbox can be used. |
redirect | Required field: Defines the URL the submitter is redirected to after submitting the HTML form. The URL has to be defined absolutely including protocol and host. Protocol and host must match the URL of the page on which the form is embedded. |
errorredirect | Defines the URL the submitter is redirected to in case of a processing error. If this parameter is omitted, the user will be redirected to the page defined by redirect. The URL has to be defined absolutely including protocol and host. Protocol and host must match the URL of the page on which the form is embedded. The error code and an error description are provided in the errorcode and error parameters. |
redirecttype | Defines how the redirect should be executed. Valid values are "302", "303", "307", all other values will be ignored. By default, the redirect is executed in the web browser by script or meta tag http-equiv="REFRESH". If this form field is set the redirect is initiated on the server by responding with the appropriate http status code and the URL in the http header "Location". |
objname | Defines the name of the created object. |
objsubject | Defines the subject of the created object. |
objcategory | Defines the category of the created object. If an objcategory is specified, fields that are assigned to the category can also be submitted as HTML fields. The Programming Name of the category fields must match the name of the respective HTML fields. The category must be usable for the created object (e.g. check property “Applicable for”). Categories created by a user form can only be used if they belong to the same cloud organization as the form inbox. |
content | Allows uploading a file, which is then stored in the File field of the generated object. This is only possible if the File property is assigned to the object class specified as objectclass. The relevant HTML field must be of type file. When saving, the system does not check whether the file extension of the uploaded file matches the data type of the object class. You can use the accept attribute in the input field to restrict the selection to specific file types. Only one file can be uploaded via this field. |
attachmentkeys | Defines the names of the HTML fields (separated by a comma) for submitting additional files. For the uploaded files, documents are instantiated in the Fabasoft Cloud, which are then stored in the property specified in the attachmentattrdef field of the instance of objectclass. The specified HTML fields must be of type file. If a value is specified in the attachmentkeys field, it is also necessary to provide a value for attachmentattrdef. The object class of the objects created for the uploaded files is determined by the file extension of the uploaded files. The file names are used as names for the created documents. |
attachmentattrdef | Defines the Fabasoft Cloud ID or the full reference of the property, in which additional uploaded documents are stored. If a value is specified in the field attachmentattrdef, you also have to provide the attachmentkeys. For object class Folder (COODESK@1.1: Folder), provide the COOSYSTEM@1.1:objchildren property. |
<Reference/Fabasoft Cloud ID of other properties> | You may also set other properties that a user can change in the properties editor. These properties are identified by their full reference or their Fabasoft Cloud ID (e.g. COOSYSTEM@1.1:objexternalkey). |
Note:
Example |
---|
<!-- Replace "form inbox ID" with the value of the ID field of your form inbox and "redirect URL" by a URL of a page that schould be shown after the form was proccessed on the server. <form action="https://at.cloud.fabasoft.com/foliop/createobject" method="post" <input name="encodingfix" type="hidden" value="☠" /> <label for="objname">Name:</label> <input type="submit" value="Send"> </form> |