Term | Description | Links |
---|
Client | Clients are the top level instance with their own forms, users, user groups, inboxes etc. Different divisions of a company can use the same Xima® Formcycle system with a different client for each division. | Client |
Cluster | Xima® Formcycle can be run on multiple servers, called master servers and frontend servers. When one server fails, another server can take over and replace that server. All servers connected to each other this way are called a cluster. | Cluster, master server and frontend server, Server communications overview |
Form | A form is a web page where users can enter and submit data, such as a contact form, order form, or support request form. | Forms, Form settings |
Form specific inbox | An inbox containing only form records of a specific form. Data columns can be customized. This allows you to view certain form fields without having to open the form. | Form specific inbox, Inbox |
frontend server | A frontend server provides users with access to forms and accepts or rejects forms that have been submitted. It does not handle management or administrative services, such as editing forms or viewing forms in the inbox. | master server and frontend server, Server communications overview |
General inbox | An inbox containing form records of different forms. Data columns cannot be customized. | General inbox, Inbox |
Inbox | Contains all forms that have been submitted, called form records. There are form specific inboxes containing only form records of a certain form, and general inboxes containing forms records of different forms. | Inbox |
LDAP | Xima® Formcycle allows you to create and manage users directly, but users can also be managed by connection to an LDAP (MS active directory). | LDAP |
master server | A master server can be used as a stand-alone and provides all of Xima® Formcycle's functionality. When frontend servers are used, the master server is also responsible for managing the connection to each frontend server. | master serverand frontend server, Server communications overview |
NTLM | NTLM can be used for authenticating users of a form. This is commonly used for internal forms of a company to identify the employees using the form, allowing the form to access the user's data via NTML. | NTLM |
Plugin (client) | Plugins extend the Xima® Formcycle by providing custom functionality. Client plugins are available only to the client who uploaded them. Plugins are written in Java. | Client plugin |
Plugin (system) | Plugins extend the Xima® Formcycle by providing custom functionality. System plugins are available only to all clients. Plugins are written in Java. | System Plugins |
Role | A role is assigned to each user, controlling the permissions of that user. | Roles |
Servlet | Servlets are run on the server when requested by the client, and can return data from the system or make changes to the system. | IPluginServletAction, Queries, Working with form URLs |
State | When a form is submitted, is in the special system state Received. Other custom states can be defined by adding them in the workflow processing. For example, a job interview form might have the two additional states Accepted and Rejected. |
|
Variable | Sometimes it becomes necessary to use the value of certain form fields within Xima® Formcycle. For example, you might want to send a mail to the address the user entered in the form. Variables can be used within fields supporting them. They will be replaced by the corresponding value by the system. | Placeholder, Alias |
Workflow processing | After a form has been submitted, workflow processing starts. Depending on the form's state, certain actions will be executed, such as generating PDF files, sending mails etc. State transitions can be performed manually in the inbox, or by the system. | Inbox, Workflow processing. |
Xima® Formcloud | Xima® Formcycle on a cloud, allowing you to edit and manage your forms online. | |
Xima® Formcycle Designer | Form editor for creating forms. | Xima® Formcycle Designer |