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 (Enterprise and higher only).
Either you can add a form to an existing object (shown in the properties of the object as first tabs) or you can create basic objects based on a form.
You can use the following form fields on your form:
You can define the following types for input fields and item lists:
Note: The type of a field cannot be changed after the form is published.
Depending on the type, you can make further settings for form fields. In general, you can specify:
For the languages available in the Fabasoft Cloud, you can provide translations for the names and context-sensitive help. To do so, open the properties of the form (context menu command “Properties”) and switch to the “Translations” tab. For each multilingual name of the form, you will find a corresponding entry.
To create a form, perform the following steps:
The form is now available as a draft. Within this Teamroom, test objects can already be created based on the draft (if you have not chosen Suppress Template Creation). The drafts can be found in the create dialog in the “Forms (Draft)” category.
After finalizing the draft, the form may be published.
To publish a form, perform the following steps:
Within this Teamroom, objects can already be created based on the published form (if you have not chosen Suppress Template Creation). The published forms can be found in the create dialog in the “Forms” category.
If necessary, you can customize the form even after the publishing. Until you publish the form again, the changes will not be generally available.
To be able to use forms in general they must be released via the context menu command “Release Form for Usage”. The release can be done either for the user only (testing purposes) or for organizations, organizational units, teams or external organizations. To release for organizational elements, you must be an organization administrator or authorized by an organizational policy to manage the corresponding organizational element. Users with the “Head” role can also release for organizational units.
To release a form, perform the following steps:
The release state can be removed by executing the context menu command again and removing the check marks for the corresponding entries.
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:
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 Teamroom templates.
To add a form to an object, perform the following steps:
The form is displayed as the first tab in the properties of the object. When you define the object as a Teamroom template, the form is available with each newly created object that is based on the template.
In the properties of the category, on the “Template Category (Component Object)” tab, in the Applicable for field, you can define object classes for which the category should be useable.
If you want to restrict a BPMN process to a form category and use activities that are allowed only for documents, you can customize the category accordingly (only “Document” must be entered).
The form category can additionally be used to define retention rules. You can find the category in the properties of the form on the “Form” tab in the Category (Published) field.
In the properties of the category, on the “Retention Rules” tab you can define whether objects with this category are retention worthy. For retention worthy objects, a retention period can be defined manually on the “Retention” tab. Within this period, the object cannot be deleted.
The retention period can also be calculated based on the category. To do so, define in the category a Retention Period and a Base Date for Retention Period. The calculation of the concrete retention period is carried out via a background task, which must be defined in the Default Background Tasks field.
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 Retention Period as Base Date for 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”.
In an inbox, rules for the processing of incoming objects can be defined. A rule consists of conditions and actions.
You can create the inbox directly on “Home” (background context menu > “New” > “Inbox”). As for Teamrooms, you can also set a team for inboxes to define the access rights.
To define rules for an inbox, perform the following steps:
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.
The Fabasoft Cloud in conjunction with Mindbreeze InSpire allows you to automatically classify documents and extract metadata (Enterprise and higher only). 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).
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, perform the following steps:
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, perform the following steps:
You can specify the following fields in the HTML form (unless otherwise specified, the fields are optional):
Field in HTML Form
Required field: Defines the Fabasoft Cloud ID or reference of the object class from which an instance is to be created in the form inbox after the HTML form is transferred.
Required field: Defines the ID of the form inbox. Alternatively, the Fabasoft Cloud ID of the form inbox can be used.
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.
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.
Defines the name of the created object.
Defines the subject of the created object.
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.
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.
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.
Defines the Fabasoft Cloud ID or the 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 fully qualified reference or their Fabasoft Cloud ID (e.g. COOSYSTEM@1.1:objexternalkey).
<!-- Replace "form inbox ID" with the value of the ID field of your form inbox.
<form action="https://at.cloud.fabasoft.com/foliop/createobject" method="post"
<input name="encodingfix" type="hidden" value="☠" />
<input type="submit" value="Send">