Cyclos administration manual

The administration help file can be accessed via the help icon in the functions windows. The help contains an explanation of all administration features. Directly under the title of each help section the location where to find the described feature is shown. The location is in italic and has a > sign in front.

For the more complex configurations instruction videos are made and published at this page. New features might not be covered yet in the videos. Another helpful resource is the cyclos feature list. Finally, Cyclos reference documentation is available at documentation.cyclos.org.

Note: Be aware that you need full administration features to be able to see all the functions that are explained in the help file and instruction videos.

Navigation in Cyclos is done via a main menu (horizontal bar) and sub menus that are shown at the left or directly under the horizontal menu depending on the screen size. When navigating more than one level deep (for example: view user profile) Cyclos will show a clickable 'breadcrumb' tree directly under the horizontal menu.

Besides the menu you can use the 'Quick actions' that show up at the home page. What actions will show up at this page can be defined in the local preferences (Personal > Preferences > Dashboard actions). The 'quick search' (at the top right) can be used to quickly search for users, contacts or advertisements. Operations that are related to users, for example editing the profile of a user or setting a credit limit, can be done from the Profile > Actions section of the user profile.

> Menu: Personal

This section is available for all admins that are not global admins. An admin can change personal settings like login password, updating profile, and view notifications. In the 'Settings' section you can define what dashboard actions will show up at the entry (home) page, and the notifications that can be sent to your Cyclos notifications inbox and/or your e-mail address. There is also an option to switch to the new front-end. Be aware however that the new front-end only supports operational administration functions, and not system configuration functions.

> Quick search: Search Users
> Menu: Users - Management
> Dashboard action: Search Users
> Dashboard action: Register user
> As guest: Link: Register (top right)

The page where you can search for users has also the option to register new users. This can be done by selecting the 'New' button. If one or more groups exist (and you have permissions to manage the group) you will have to select the group first.

If public registration is enabled (in the configuration) users can also register themselves via the option 'Register' at the main page (when not logged in).

More information about registration settings can be viewed at manage configurations.

Detailed information about user visibility can be viewed at this help section.

> Quick search: Search Users
> Menu: Users - Directory Map

The Directory Map allows searching users on the map. The same search filter (fields) are available as the normal user search.

Information about the Map configuration can be viewed at the configurations help section (see 'Maps & Directory').

> Menu: Users > Management > Contacts

Users can have contacts that can be managed (add & remove) by an admin or broker. Selecting a contact of the contact list will bring you directly to the user profile of the contact. If needed specific 'contact fields' can be created (in menu System - User configuration - Contact fields).

Users can also have internal contacts, for example a business can have a contact for sales and for bookkeeping. These contacts are described in the next section (company contacts).

> Menu: Users - Management - User profile
> Menu: System -User configuration - Contact fields
> Member product: General >Maximum public contact information
> Admin group permissions:User management > Manage public contact information

Companies usually have various internal contacts that each have their own email addresses and telephone numbers. When the permission is set users (or their brokers or admins) can add additional company contacts. The contacts will be shown in the view profile page (at the bottom) and the contacts can be managed from the edit profile page.

If needed custom 'company contact fields' can be created (in menu System - User configuration - Public contact fields).

> Menu: Users - Management - Connected users
> Menu: Users- Management - User profile

An administrator can view all connected users (see location above) of the users he can manage. From the connected users list an administrator can disconnect them or go into their profile page.

> Menu: Users - Management - User profile

From the user profile page you can click the edit icon (next to the username in the title) and update the user profile fields. From the edit mode page you can also update the user addresses, phones, public contact information and profile pictures. When a custom operation exists (of type 'User') an action button will appear below the profile.

> View user profile - Banking - Payment system-to-user
> Menu: Banking - System payment - To user
> Menu: Users -Management - User profile

From the above mentioned locations an administrator can perform a payment to a user. Depending on the permissions this can be from a user account to a system account, from a system account to a user account, and from a user account to another user account. If there is more than one origin account you will have to select the system account the payment will be done from. If there is one or more possible user (destination) account you will have to choose one. Most systems have only one possible payment type defined. What means no payment options will be shown.

> View user profile - Banking - Payment system-to-user
> Menu: Banking - System payment - To user
> Menu: Users -Management - User profile

With batch payments members can perform payments to multiple users in one batch. This can be done by importing a file with the destination users and the amounts to be paid (and optionally description and other fields). The batch payment feature has a preview function that will show detailed data about the batch to be performed (how many users, possible failed users, amount per user, total amount). There is also a history that will show this data per batch.
Admins that have the permission can perform batch payments on behalf of the user (from the user management page).

Information about user batch payments (e.g. file import format) can be found at the wiki page: User payments import

> View user profile - Accounts - Account limits
> Menu:System - Products - Select Member product - Account section
> View user profile - Banking- Account limits
> Menu:System - Banking - General overviews - Account limits

An administrator can define a personal credit limit for an individual user or a credit limit for a whole group of users. This can be a negative credit limit which means the user can start with a zero balance and go negative (mutual credit model). For economic models that work with positive balances a payment coming from a system account will need to be configured in order to provide credit for users. It is possible to define a default credit limit automatically for new registered users. To set a negative default credit limit for a group of users go to a Member product with an account, then go to the Account section and set the 'Max. negative account balance'. An initial positive balance can also be configured in the Account section of a member product, under the option: Initial credit (you will have to select a system-to-user transfer type).

Note: In the account limits overview page you can search on individual credit limits.

> View user profile - User management - Groups

In the manage group page you can move users to other groups. Be aware that a different group could have different products, which means the user could get different features and permissions. More information about groups can be viewed at: manage groups.

> View user profile - User management - (block, disable, remove, purge)
> Menu: Users - Connected users

As an administrator you can block or disable users temporarily. A user with the 'blocked' status cannot login via any access channel but will be active in the system, which means other users can see him/her and he/she can receive payments. Disabled users cannot login and are not visible by other users in the system (except for brokers and administrators). Removing users is irreversible, removed users cannot be set as active anymore. They will remain in the database for backup reasons. When removing users all advertisement and profile pictures will be removed. The user and transaction data will be kept, but will be only visible for administrators and brokers (with the permissions).

The user search has a status option where you can filter by the above mentioned status, and also by the 'pending' status. Pending users are users that have registered at the public registration page and did not confirm by email yet.

When a user has the removed status he/she won’t be visible in any way to other users, and no operation related to this user is possible. It is as if the user was removed from the system, but the user data is kept and is accessible for admins (with the permissions). The reason that the user data is kept is because this is often required for financial institutions. However, when needed it is also possible to 'purge' users, this means that all private data is completely erased. A system admin can define which private data (e.g. addresses, custom fields, built-in fields, record types) is erased on purging.

> View user profile - User management - Passwords

An administrator or broker (with the permissions) can manage the passwords of the user from one page. A password can be blocked and changed. It is also possible to reset the password. What means a new password will be generated and sent by email.

> View user profile - User information - Record
> Menu:Users - Records

Administrators and brokers can manage user 'records' for a user from user profile and view a history of records for that specific user. From the menu administrators and brokers can search for records given to all users.

Records are a generic way to store and retrieve user data in a structured way. More information about user and system records can be found here.

> View user profile - User management - Products

At this page you can view the (permission) products of a user and assign an individual product to a user. Be aware that usually products are assigned at group or group set level. Information about permission products can be viewed at the manage products help section.

> View user profile - User management - Channels access

Here you can define what channels the user has access to. This setting will overwrite the channels defined in the product.

More information about the channels can be viewed in this help section.

> View user profile - User management - Card (token) name

Here you manage the cards (tokens) of a user. Administrators (with permissions) can create, activate, block/unblock cards and change the expiry date.

More information about cards (tokens) can be viewed in this help section.

> View user profile - User management - Brokers

An administrator can assign a broker to a user and in the case a user has multiple brokers one broker can be set as 'main' broker. Information about brokers can be viewed at the manage products help file.

> View user profile - User information - Documents

An administrator or broker can upload a document (file) and attach it to a user. A typical individual document would be a digital copy of a passport. The page will also show the shared documents that are assigned to the user product.

> View user profile - User management - Configuration

This page shows the 'active' configuration of the user. The active configuration is the end result of the combined configurations that are applied to the user.

For more information on configurations please view the configuration help file.

> View user profile - Advertisements - View user ads
> Menu: Users Advertisements - Search advertisements

Administrators can manage advertisements of a specific user from the user profile. Administrators can search for advertisements of all users from the User management menu. The advertisement permissions can be defined in the user product (Advertisements section). The visibility of advertisements for guests is defined in the configuration (Visible advertisement groups).

> View user profile - User information - References

Administrators can manage the references of a user from the user profile. It is possible to edit existing references. If users exceed a certain number of maximum received or given negative references an alert can be sent. This can be defined in the configuration (alert section).

> View user profile - User information - Send message from system
> Menu: Users - Messages - New message
> Menu: Users -Messages - Search messages
> Menu: Users - Messages - Mailing lists

Administrators can send an individual message from the user profile. When sending a message a message category needs to be selected. From the user management menu (see location) an administrator can send messages to an individual user or to user groups (mailing). It is possible to send mailings via different channels, currently SMS, email and mobile app push messages are supported. After defining a mailing a preview page will be shown (and variables applied if any) and it is possible to send a test mailing message to an email or mobile phone.

A history of sent and and received messages is available under the Menu: Users - Messages - Search Messages. When selecting a mailing from the mailing list it will give information about the mailing (e.g. number of successfully sent / failed messages).

> Menu: Banking - General overviews - Payments

Here you can have a quick overview about all the payments in the system. The latest (most recent) payments are listed on top. It is possible to search/filter by various criteria. The page will show the number of transfers from the search result list, and the sum of all those transfers. There is also an option to export the transactions to a CSV, Excel or custom format file.

> Menu: Banking - General overviews - User balances

This feature provides a way to have a quick overview of users and their account balances. The feature consists basically of a list of users with their account balances. Clicking on a user in the result list will jump to the profile of that user (it is possible to go back to the balances search with the navigation toolbar). There are various search (filter) options and a 'show on Map' option. The map shows only users that have addresses. The filter options are mostly the same as the normal user search, and there are some additional filter options. It is possible to filter on a 'balance range'. This will allow you for example to retrieve a list of all users with account balances between 500 and 1500.

With the 'yellow range' option you can define colors that will appear in the search result list and the Map. For example, when the yellow balance range is set '-200 to 200' the users balances that fall within -200 and 200 will show up as yellow (account balance in list or marker in the Map), users below -200 will show up as red, and users above 200 as green. A default yellow range can be defined in the account type. Be aware that the yellow range option does not 'filter' anything, it just defines that the account balances for the given search result will be shown with colors according to the balances. When clicking on a marker in the map it opens a pop-up with the user information (name and balance) and it has a link to jump to the user profile. You can go back to the map with the breadcrumb navigation. The map has a full screen option which makes it easier for results with many users. You can go back from the full screen mode to normal display mode by clicking the 'x' at the top right of the (full) screen.

Above the user balances list some information is displayed (based on the search result). Currently it displays the total sum of positive/negative balances and average negative/positive balance.
There is also an option to export the transactions to a CSV, Excel or custom format file.

> Menu: System - Products - Select Member product - Accounts -Balance limits
> Menu: Banking - General overviews - Account limits
> Manage user (from profile): Banking - Balance limits

Accounts balances can be limited, meaning that it is possible to define a maximum and minimum account balance. When a negative balance limit (overdraft) is set, it means that the user cannot make any payment if the balance goes over the limit. The user will have to top-up his account or receive a payment in order to be able to make payments again. When a positive balance is set the user cannot receive any more payments when the limit is reached. The account balance limits can be defined at product level and individual level. There is a general overview page of account limits per user.

Various search filters are available. It is possible to enter an account limit from the search results. From this page an admin (with permissions) can change the account limits (this can also be done from the user profile). Account limit changes are always stored to the history log (tab) with the user that performed the change, the values of the change and a time stamp.

There is also an option to export the account limits to a CSV, Excel or custom format file.

> Menu: System - Products - Select Member product - Accounts -Payment limits
> Menu: Banking - General overviews - Payment limits
> Manage user (from profile): Banking - Payment limits

It is possible to define minimum and maximum amounts limits for payments. As with account limits the payment limits can be defined at three levels: in the transfer type, in the product, and at individual level (at the management section in the user profile). In the transfer type it is possible to define the max amount per payment type per day/week/month/year, and the max number of payments, also per day/week/month/year. The payment limits in the transfer type are leading (they cannot be overwritten by product or individual settings).

An admin or broker with the permissions can also define max amounts at individual level. The individual max amounts will overwrite the default settings in the product.

From the user profile (management section) there is a page that will show all active payment limits for the user, and an option to change them. There is a general overview (search) page for all payment limits. There is also an option to export the payment limits to a CSV, Excel or custom format file.

> Menu: Users - Management - Bulk actions

The bulk actions feature allows running specific actions over a (bulk) selection of users. The bulk actions can be run by an admin or broker. Running a bulk action starts with the selection of users. The user selection includes most of the filters of the current user search, and it has an optional search filter for each profile field. An admin or broker can add or remove specific users manually from the selection (by using select boxes). When the user selection is ready to be processed, the admin or broker can choose either to run a 'built-in' action (reset password, change group, change product, change profile field value, re-index) or run a 'custom bulk action' (a new 'bulk action' script type is available). A custom bulk action can display an input form with any necessary (custom) fields that are needed for the action. A custom bulk action can be assigned to a product. Of course the broker bulk actions can only affect his 'brokered' members. As well the built-in bulk actions as the custom bulk actions will log information to a history log which is accessible and can be searched in. The history log will show a list with all bulk actions with their status (Pending, Success, Error). The details of each bulk action will show information about the action such as the creation and run date, the person who performed the action, the number of applied users with the status (success, failed, skipped) and actions buttons depending on the status (e.g. re-run on failed actions).

> View user profile - User information - Notification settings
> Menu: System - User configuration - Product (permissions) - Messages & Notifications

At this page you can change the notification settings for the user. Be aware that the possible notifications can be defined in the user product. In the product you can define as well if a notification is enabled by default.

> View user profile - User management - Profile history
> View record (system or user) - tab 'History'

All changes to user entities (e.g. profiles, phones, address, advertisements, records, tokens) are stored in the History log, which is accessible for brokers and administrators. In case of a record the history log is only enabled when the record type is editable. When a user profile or editable record is saved the history log is written. Going into the history log (from user profile or record details) there is a list with changes. In this list it is possible to search by field name and period. Selecting a specific change in the list will open the log details page. This page shows the new and the old value, the date/time stamp and the IP address of the user that changed the value.

The history logs is accessible via the user management section (in the profile page of the user) and there is also a general User logs search in the reports menu (Alerts & Logs - User logs). The general user logs function is explained in this section.

Note: Cyclos also has system level logging. Any operation in Cyclos is also logged into a log file or a database (depending on the configuration).

> View user profile - User management - Account information - Archived history button
> View user profile - User management - Account information - Archived history button - transaction details tab
> System - Groups - Admin group details - View archived accounts

It is possible to archive all transactions in Cyclos when they are older than a specific time. For example Cyclos could maintain only 3 years of transactions, and the archived transactions can be stored automatically in a separate database. Archiving transactions is only useful for systems with very large databases (more than 100 Gb). A common first step to limit the database size is to store the images and other files outside the database, in a file storage service.

When database archiving is enabled (in the cyclos.properties file) an admin can be given permission to view & print archived transactions.

More information about data archiving can be found in the online documentation page.

> Menu: Users - OAuth2 / OpenID Connect - Clients
> Menu: Users - OAuth2 / OpenID Connect - Authorized applications

AOuth clients allow access from third party software to Cyclos (via the API). There are two types of OAuth clients. Static clients (created manually by an admin) and Dynamic clients, that can be created by users 'on the fly' via the API.
For users to be able to create dynamic clients the setting 'Dynamic OIDC clients' must be enabled (in the configuration bound to the group of the user)

More information about OICD/OAuth can be found at the wiki page: Wiki4 - OpenID Connect - OAuth2

> Menu: System - Accounts configuration - Currencies

Before creating accounts a currency needs to be created. A currency has a format (pre and suffix) and a symbol. When creating a new account a currency needs to be selected. When a transfer number is defined in the currency all transactions within the currency realm will get a unique (generated) transfer number.

> Menu: System - Accounts configuration - Account types
> Menu: System - User configuration - Product (permissions) -Accounts
> Menu: Banking - System accounts - Account summary

Accounts in Cyclos can be either of the type "System" or "Member". Both types are related to a currency and can contain units that can be transferred to and from other accounts (if transaction types between these accounts exist). If a new account with the type "Member" is created it is just an empty account type and cannot be accessed by members. In order to enable a member account an administrator will have to enter a member product and associate the new account to the product. By doing this all members with that product will have such a member account. Even though there is one member account configured in the system each member will have their own account balance and their own payments. Members can have zero, one or more member accounts (assigned via products), and make payments between their own accounts, to other member accounts and to system accounts. A member account can have a generic name visible for all account owners, for example, 'checking account'.

Contrary to a Member account a System account is a single 'stand alone' account, it will just have one account balance for example. A system account is not directly associated with specific users but administrators can be given permissions (defined in a product) to make payments from the account to other system or member accounts. A system account can be either 'limited', which means it can be given a max negative and positive balance, or 'unlimited', which means it can go indefinitely negative or positive.

> Menu: System - Accounts configuration - Account types - Member account
> Menu: System - User configuration - Product (permissions) -Accounts
> Menu: Banking - System accounts - Account fees

Account fees are payments from multiple members to a system account or the other way around. Usually they are scheduled to run in a period (e.g. monthly) but they can be configured to be run manually as well (by an administrator). Account fees are related to an account and can be activated for one or more Member products. When an account fee is levied, all member groups that have been selected in the account fee configuration will be charged. However, though the word "fee" suggests that members are paying, an account fee can also be configured that a system account is the paying party, and that members receive the fee. A typical account fee is a monthly contribution payment from members to a system account (but it can be the other way around as well). Another example is "demurrage" or "liquidity tax", where users pay over their positive balance through time, as a sort of "negative interest".

Detailed information about authorizations and roles can be found in the online specification page.

> Menu: System - Accounts configuration - Account type - Transfer types
> Menu: System - User configuration - Product (permissions)- Accounts
> Menu: Banking - Account summary - Account -Transaction details

Transfers that have been done can be viewed in the Account summary page when clicking on a transfer from the history list. Transfers can happen from or to 'system accounts' and 'user accounts', as explained in the account section above. Each transfer (or payment) will have a 'Transfer type', which can be seen as the 'blue-print' voor transfers. The transfer type contains the configuration. It defines for example the origin and the destination account type of the payment and many other settings. A new transfer is always created from within the origin account (the account of the payer). The transfer type has many configuration options, for example 'max daily limit' or 'require authorization'. The 'confirmation text' of a payment will show up in the confirmation dialog window when the user has to confirm the payment. The transaction type can also be bound to a specific channel. For example, a transfer type 'mobile payment' could be created and only be associated with the SMS channel. This way the transfer type will only be available for SMS operations.

*Note*If you want to enable the option to 'charged back' (undo) payments you will need to specify a max. chargeback time in the transfer type. When a chargeback is done a payment in the opposite direction will be done in order to cancel out the payment (a payment can never be removed). Be aware that admins and brokers will need to have specific permissions to charge back payments.

Detailed information about transfer types can be found in the online specification page.

> Menu: System - Accounts configuration - Account types - Transfer type - Transfer fees

A transfer fee allows charging a fee automatically when a specific transaction occurs. For this reason a transaction fee is configured within a transfer (you have to go into a transfer, which has a 'transfer fees' tab). There are various ways to calculate the fee (e.g. fixed amount, percentage of payment amount) and there are different options to define who will be charged and who will receive the fee (destination). For example either the payer or payee can be charged, or even another (fixed) user. The beneficiary (receiver) of a fee can be the payer or payee, a system account, a fixed user or the broker of the payer or payee.

A typical example of a fee is a transaction fee on a trade transfer. If a broker receives the fee it could be considered a 'broker commission'. There can be more than one fee attached to a transaction. Because of the many ways fees can be configured it is not necessarily always a "fee". For example it is possible to use a fee to "forward" and "distribute" payments to other accounts (using the percentage option).

A normal fee will always be applied 'on top' of the original payment. For example, a fee of 3% on a transaction with the amount 100 will result in a total amount of 103 being debited. When using the 'deduct' option the fee amount will be deducted from the original amount. That means in the above example that the fee charged will also be 3, but the payment amount will be 97. When creating a new fee you have to specify the 'transaction type' that will be used when the fee is charged. It is common practice to create a new transaction type for a fee so that users can filter on fee transfers. Fees can also be charged within another currency.

Detailed information about transfer fees can be found in the online specification page.

> Menu: System - Accounts configuration - Payment fields
> Menu: System - Accounts configuration - Account types - Transfer types - Payment fields

If needed a custom payment field can be added to payment types, with specific validation and other options. Just as a transfer fee a payment field can be added from within a transfer type. A payment field needs to be created first in the account configuration (see location above) before they can be added to a transfer type.

General information about custom fields can be found at this section.

> Account history - Transaction details - Status
> Menu:System - Accounts configuration - Payment status flows
> Menu:System - Accounts configuration - Account types - Transfer types -Transfer type details

It is possible to define status flows for specific transaction types. The first (initial) status of a flow is set when the payment is performed. Users (with the correct permissions) can search in the account history by status and each payment details will show the status and a history log with the status changes. In the payment details page the status can be changed (to the next status) by members, brokers and administrators, depending on the status flow and permissions.

Administrators can create and manage 'status flows'. Each status can have one or more 'possible next' status. A status that has no 'next' status is considered as final (closed) which means that it cannot be changed. There can be one or more possible 'initial' status, intermediate status and final (closed) status per status flow, and there can be none, one, or various status flows per transaction type. The transaction type will define what status flows it uses, and the initial status of each flow.

The status feature is very generic. It can be used for any payment type where you want to follow-up with actions that can be done (or must be done) after a payment has been made. A simple example of a status flow would be an initial status 'open', for example when a loan payment is made, and a (final) status when the loan is repaid. Another example would be a member-to-member payment where the payment receiver can set the payment status to 'product sent', after which the payer can set a final payment status as 'product received'. These are very simple examples, any type of flow and status can be configured. Each status flow and/or specific status can have their own permissions (none, view only, modify). It is also possible to implement specific behavior of status field changes and possible flows by creating a status extension point that uses a script of the type 'status'.

> Menu: System - Accounts configuration - Account types - Payment filters

It is possible to group transfer types into 'Payment filters'. These filters allow handy grouping together of certain related transfer types so that you can use it as a filter in the account information list. For example: different kinds of payments from a user to a system account can be grouped into one filter with the name "System payments".

> Menu: System - Accounts configuration - Authorization roles
> Menu: System - Accounts configuration - Account types - Transfer type details
> Menu: System - User configuration - Product(permissions) - Accounts - Payments authorization

Cyclos can be configured so that payments need to be authorized first before the amount is really transferred to the receiver’s account. As long as the payment is not yet authorized, it will stay in the "waiting for authorization" status. Both member (payer) and the authorizer will have access to a list with pending payments that need authorization. The paying member and authorizer will be notified and the authorizer can authorize (activate) or deny the payment.

If you want to enable authorization for a transaction type you have to select the check box "requires authorization" in the transfer type. Once the transfer type is saved an extra tab called "Authorization levels" will appear. There are three types of authorizers that can be defined in the authorization configuration, the payee (receiver of the payment), the broker of the paying user, or an administrator. If you want an administrator to be an authorizer an 'authorization role' will need to be created first (see location above). Once an authorization role is created you can use it at an authorization level. After adding the role to an administrator group the administrators of the group will be able to authorize the payment (at the level defined). It is possible to have more than one authorization 'level'. This means that after a payment is authorized another administrator or broker would need to authorize. When the last level is authorized the payment will be done and the payer will receive a notification.

It is possible to define an amount range in an authorization level. If an amount range is configured the authorization level will only be applied when the transaction amount is within the amount range. The range can be configured with an 'upper' and 'lower' limit, but it is also possible to select just one option. For example, if only a lower limit of 100 is defined (and no upper limit) any payment above 100 will apply.

Detailed information about authorizations and roles can be found in the online specification page.

> Menu: System - User configuration - Product - Payment feedback
> Menu: System - Accounts configuration - Account types - Payment type - Enable payment feedback
> Menu: System - User configuration - Product - Payment feedback
> View user profile -User information - Feedbacks

It is possible to enable a feedback or 'qualification' for payments. This is defined in the transfer type and the user product (see above locations). Every time a user makes a payment he will be asked to qualify the payment/trade. Payment qualifications have many options (defined in product). A user can view the feedback that is given to other users. A user can disable payment feedback for specific users. Qualifications can be disabled for specific users. This is common for frequent trading partners (as you don’t want to be required to qualify every payment).

> Menu: System - Accounts configuration - Account types - Transfer type
> Menu: System - User configuration - Product (permissions)- Accounts
> Menu: Banking - System accounts - Scheduled payments

A transfer type can be configured to allow 'scheduled payments'. A scheduled payment is a transfer which is to happen in the future, but is already agreed upon and scheduled. It can be scheduled for a single future date, or for future 'installments' at specific dates (defined by the payer). A scheduled payment can also be 'recurring', meaning it will happen at intervals defined by the payer (daily/weekly/monthly/yearly). The payer can also set the first recurring date and the number of occurrences (a fixed number or indefinitely).

When the date of a scheduled payment is reached the payment is debited from the payer account to the receiver account. A user or system administrator can see an overview of the outgoing scheduled payments,and optionally all incoming scheduled payments as well. Depending on the configuration a scheduled payment can be canceled, blocked, unblocked and processed in advance. Notifications can be sent for scheduled payments (to payer and receiver) and for any status change.

> Menu: Banking - Payment requests
> Menu: System -Accounts configuration - Account types - Transfer type
> Menu:System - User configuration - Product (permissions) - Accounts
> Menu: System - User configuration - Groups

A payment request is a way to request a payment to another user for a fixed amount and an expiry date. The person that sends the payment request can also define if the repayment will have to be paid for the whole amount or if it can be paid back with installments (scheduled payment). The payment request can be accepted (or denied) by the receiver as long as the expiry date is not reached. On every action or status change a notification will be sent to the sender and receiver of the request. Payment requests can be sent to and from members, and to and from system accounts. Different channels can be enabled for payment requests. For example, it is possible to send a payment request from a phone with an SMS message. A request can also be sent from the web interface, and received/accepted by SMS. In case the payment request is sent by SMS the text message will contain a temporary code that the receiver will have to include in the reply (in order to accept).

> Menu: Banking - Pay external user
> Menu: System - System configuration - Configurations - Select configuration - Channels

It is possible to send a payment to users that are not registered in the system. For example, a user (or admin) can make a payment to an external email or mobile phone number. For the payer the amount of the payment will show up as a 'reserved' amount, meaning it cannot be used until the new user (payment receiver) confirms the payment. The payment receiver will be informed (by email or SMS) that he has a pending amount to receive, and that this can be retrieved by registering to the system (either via Web or with SMS, depending on the configuration). Directly after the registration the amount will be transferred automatically from the payer to the receiver account, and the reserved amount at the payer account will be canceled. If the user does not confirm & register within a certain (configurable) period the amount will be freed from the reserved amount back to the available amount of the payment initiator. As well a user as an admin (with the permissions) have access to an overview page with all external payments and their status (e.g. success, failed, expired, canceled).

In order to configure external payments make sure that a valid identification method is selected in the channel (under section Perform payments, option: 'User identification methods for performing payments').
For a user to be able to perform external payment the product option: Accounts - External user payments, must be checked.

Businesses and users can generate QR codes and payment URLs that contain the receiver, amount, description and possible custom payment fields. The QR codes and URLs can be printed (on an invoice) or sent by email to groups of users. The users can confirm the payment with their mobile phone (as described above) or by clicking the payment URL in the email. An example is demo.cyclos.org/pay?to=demo&amount=10

Note: Be aware that the easy invoice is just a link to a payment, it does not generate a payment request or a ticket.

Detailed information about easy invoicing and tickets can be found in the online specification page.

> Menu: System - System configuration - Networks (global administrators only)

Networks are the highest level categorization in Cyclos. The network structure allows running independent environments (networks) in the same (shared) system. Networks can only be managed by 'global' administrators. Users that are in a global administrator group can create and manage new networks, and give administrators permissions to manage specific networks. Global administrators typically only define high level system administration such as adding languages, creating networks and defining properties for networks, such as the network domain/URL. Each network will have a built-in 'network administrators' group. Administrators that belong to this group have full permissions over the network. Network administrators can configure a new system with all the available elements such as products, account types, user groups, group sets, etc.

For any user in the system that is not a global administrator (e.g network administrators and normal users) the network environment will appear as a single system. Running multiple networks in shared (networked) environments is very similar to running separate Cyclos installations next to each other. The main difference is that with a shared (networked) solution interaction among networks can be enabled, for example user searches and payments.

If your installation runs a single project just one network would be enough. If there is only one network in the system it will be marked automatically as the 'default' network. What means that when accessing the main URL you will enter automatically in the network scope. If you want to login as global (system) admin you will be always able to access the system with the global URL path. For example: www.yourdomain.org/global). If you want to run more than one project (network) in a single Cyclos installation you can just add new networks. In case you run more networks the default network is usually just to display pages and information for the 'umbrella' organization.

Detailed information about networks can be found in the online specification page.

> Menu: System - System configuration - Networks (global administrators only) - New network

Setting up a system from scratch requires considerable effort. In order to facilitate the setup and configuration of a network a network wizard feature is available. The wizard will lead you step-by-step through the setup. Each step has an input form and includes an explanatory text. The settings defined with the wizard can be modified afterwards going to the specific entity. For example, if you want to change an account name you can do that in the account configuration.

Even though the explanatory texts in the steps should be sufficient to setup a system we suggest to have a good read through the Account configuration and System configuration sections.

> Menu: System - Tools - Wizards

A wizard in Cyclos is a 'flow' of steps where each step is a page that can contain form fields or built-in functions. It works much like a custom operation, but where a custom operation consists of a single page, a wizard is a flow of pages with a first step (page) and a last last step (the finish). On the submission and loading of each page/step script code can be run. Wizards can have their own custom fields, and it is possible to store and fetch values between steps.

Within the flow there can be different 'branches' according to the options chosen by the customer. A wizard can be shown in a menu for guests or logged users, it can appear in an existing menu or a custom menu, it can be accessed via an easy readable URL, and it can be used for the registration of new users. The wizard has various available built-in features. For example, integration with external identity providers such as Facebook or Google, email validation, captcha etc. It is possible to integrate a step with a third party service, for example for KYC (know your customer) purposes.

More information about wizards can be found in the online documentation page.

> Menu: System - User configuration - Groups

A group is basically a container for users. Groups at their turn can be added to a 'group-set', which is just a container of one or more groups. A user is assigned to a group at user creation, and can be moved to another group at a later stage. Users cannot be assigned directly to a group-set, but will become part of the group-set when their group is added to the group-set. A user can only be part of one group, and a group can be assigned only to one group set. This means that group-sets can never share the same groups with other group-sets. Be aware that you cannot change the group-set of a group once the group-set has been assigned to a product.

Because groups and group-sets are merely containers and do contain little information and settings themselves, they offer a flexible way to manage users. The actual permissions, visibility and access rules are defined in products, which can be assigned to groups and group-sets. By assigning products to groups (or group-sets) the users of those groups will get their permissions and rules. In the group and group-set details page all products that are assigned to that group are listed in the page under the 'Products' tab. At this page you can also add new products to the group or group-set.

There are some minor but important business rules concerning group types. If you want to add a product of type 'broker' to a group the group must be as well of the type 'broker'. It is however possible (and common) to add a member product to a broker group (as explained further in the Products section ). The administration permissions are defined directly in the group (permissions tab), however, it is also possible to create admin products and assign them to an admin group. This is usually only needed for complex systems with many administration groups. When different admin groups have many duplicated permissions it is better to create a shared admin product and assign it to all the admin groups.

Where products contain most permissions, the more 'static' settings (e.g. date format, time zone, application name etc.) are defined in configurations. A configuration can be assigned to a group at the 'Configuration' tab. Information about the Configurations can be found at the Configurations section.

> Menu: System - User configuration - Products

All the permissions and access rules are defined in 'Products'. Therefore products play a very central role in the Cyclos system. The product structure allows maintaining rules and permissions in a single entity. This avoids having to duplicate settings and permissions among various groups. A product can be assigned to an individual user, a group and a group-set. Products are 'cumulative', this means that if a user has more than one product assigned (via group, group-set or an individual product) the sum of all permissions will be applied (in case of conflicting settings the less restrictive will be applied). An administrator can always see from the user profile the 'final' (combined) product that is applied to the user.

A product is by default enabled for all access channels. It is possible to restrict a product to be bound to a specific channel, for example the 'Mobile App' or 'Web services' channel. This can be done with the setting 'Product applied to channels'.

There are three types of products: member product, broker product and admin product. The member is the main product for end-users (non admins). The broker product contains mostly broker features. Please note that if you want a broker to have typical member functions (e.g. having an account), you must create a broker product as well as a member product (containing the account) and assign it to a broker group. Administration permissions are defined directly in an administration group (under the permissions tab), but for more complex configurations with many different admin groups it is possible to define the common permissions in a 'shared' admin product. For systems that have few admin groups, or admin groups with little common permissions it is not necessary to create administration products.

Below the most important sections and fields of the products are explained.
Detailed information about networks can be found in the online specification page.

> View user profile - User management - Operators
> Menu:System - User configuration - Products - Operators

Operators can be seen as 'sub users' of a Cyclos user with a member product (no broker or admin). Operators are commonly used for companies that have more than one person working with (the same) company account. Using the operators the company can keep track of who did what (e.g. payment). Another typical use of operators are cashiers at shops or cash-in / cash-out points.

Operators have their own login name and profile fields, and they can have their own cards and mobile phones, but do not have their own account or any other Cyclos entity like advertisements and references. Users (with permissions) can create operators and assign permissions to them, for example to create advertisements and perform specific payments. Also the user can set rules and thresholds like a maximum daily transaction limit (for each transfer type). An operator can never have more permissions than the main user has himself.

Two types of operators exist. The first one is merely an alias for the main user. So it is just an extra user that has the same permissions as the main user. The second type is an operator that is part of a group. The main user can create operator groups and set permissions and rules in the group. When creating a new operator a group will need to be selected in the creation form. The new operator will get the permissions defined for the group.

The user has various controls over its operators. The user can for example see the connected operators and disconnect them if needed.

And the user can list all transactions made or received by specific operators. Administrators and Brokers can also manage operators (via the profile of the main user or via the menu option: Users - Management - connected users).

> Menu: System - System configuration - Configurations
> Menu: System - User configuration - Groups - Select group -Configuration (tab)

Most settings in Cyclos can be defined in a 'configuration' (system wide settings are defined at server level in the cyclos.properties file). In the user group or group set you can define what configurations will be used (under the configuration tab). When creating a new configuration you will have to 'extend' an existing one. This means that a configuration is always part of a hierarchical configuration 'tree'. A lower level configuration will always inherit 'higher' configurations settings. For example, when a high level configuration has the 'Session timeout' value set to 10 minutes, an administrator editing a lower level configuration can change (overwrite) the value by selecting the 'edit icon' at the right of the session timeout setting. Once edited a delete icon and a green lock will appear. When selecting the delete icon the original (higher level) value will be restored. Clicking on the green lock the lock will turn yellow and will be closed. This means that the setting cannot be overwritten by lower level configurations. When a higher level configuration has blocked a setting in this way a grey lock will be shown for administrators that view the setting at a lower level configuration, meaning they cannot change the value.

All sections and fields are described in detail in the online specification page. This manual contains a brief overview of the configuration sections and options. Most of them are self explanatory.

The main section (top of page) contains the basic settings such as name and description and the URL. All configurations that extend the default configuration will have an extra option called 'path'. For example, if the main URL is cyclos.org the path could be 'demo', and when typing the domain/path in a browser window (eg. cyclos.org/demo) this configuration will be applied.
When a path is defined a section 'Data visible to guests' will appear at the bottom of the configuration page (this option is always available for the default configuration)

Note: After changing the configuration settings be sure to save the configuration by clicking the 'Save' button at the bottom of the page.

> Menu: System - System configurations - Channels
> Menu:System - Configurations - Configuration details - Channels
> Menu: System - User configurations - Password types

An access channel is a method via which Cyclos can be accessed. The most common access channel is the 'Main' Web Channel, which can be addressed via a Web browser. Cyclos comes with the following built-in channels: Main web, OAuth2 / OpenID Connect, Web services, SMS, Pay at POS, Mobile App, Ticket and Easy invoice. It is also possible to add new channels, for example for communication with third party software. When a user, or third party software, accesses Cyclos via a Channel an identifier and authentication needs to be provided. This is typically a userID and password, but different types of identifiers and authentication methods can be configured.

In the Channel you can specify what identification method is required for users (or third party software) that accesses Cyclos via that specific Channel. This can be any (unique) profile field such as email, custom field, and mobile phone number, the account number (if configured) or a 'token', which can be a card or bar/QR code. There are various authentication options: login password, transaction password/PIN, OTP and Trusted Device. A Trusted Device is a device that runs the Cyclos mobile app and has been confirmed by OTP (via SMS or email). It is also possible to create a customized password type using Cyclos scripting, and you can delegate the authentication to an external service. Users can also register and authenticate with external identity providers such as Google and Facebook.

Detailed information about Channels can be found in the online specification page.

The SMS module comes with many operations like payment, account information retrieval, and payment requests. You can also create your own custom SMS operations. The SMS is further used by other Cyclos modules like mailings and OTP (one time password). In order for the SMS operations to function an SMS gateway provider needs to be configured in the configuration (section: Outbound SMS messages).

Detailed information about the SMS operations and configuration can be found in the online specification page and the SMS quick steps wiki.

> Menu: System - User configuration - Password types
> Menu: System - Configurations - Configuration details -Channels

Passwords in Cyclos are used for two main actions, logging in, and confirming a payment. Cyclos comes with four default password types that are defined in global mode (login password, PIN, transaction password and OTP or 'One Time Password'. Be aware those password types are not 'built-in' (hardcoded), but they are created automatically the first time Cyclos starts up, and can be removed by an administrator. In network mode you can either use the global password types or create your own ones. The password types can be enabled in the Channels. In the Channels you can set the password type used for access (e.g. login) and payment confirmation. The SMS and POS channels only have the confirmation type of password, this is typically a PIN. When creating a custom password type you can choose from the following 4 modes:

> Menu: System - System configuration - Languages
> Menu:System - System configuration - Configurations - Localization

Cyclos comes with several built-in languages. A language is a single definition for the two Cyclos modules that deal with translations, being: the application translation (all build-in keys in Cyclos such as menu items and form labels), and the data translation (all translations that are defined by the admin when creating new elements, for example an account name). Both application translation and data translation are explained in detail in the Content section below.

When Cyclos is translated to a new language we add it in the next release. It is possible to add new languages in global mode based on existing languages. The languages will be available for all networks in the system. When a language is available in the system, but not listed in the languages list, the global admin can create it using the Template option in the language creation form. It is very rare however that you will need to add languages in global mode. Usually the language management and translation configuration is done within the network scope, because this is where most Cyclos entities exist. For example, you can only create an account (and give it a name) within a network, not at the global scope.

Before being able to change translation keys (either application or data translation) in the network scope a language needs to be created first (by the network administrator). In the language creation form you have to select what existing language you will extend. Once the language is created the application translation and data translation items will show up in the content menu. From these pages the keys can be modified. Usually you will give specific content administrators permissions to manage the translation keys. The language creation is considered a one-time system administrator task.

It is possible to configure multiple languages in the same network and bind them to configurations (option: Localization - default language in the configuration). This way you can configure different groups to have their own language. It is also possible to define multiple languages for the same group (in Configuration - Localization - Allowed languages). This can be necessary in countries with multiple languages like Switzerland and Belgium. As an admin you don’t know the preferred language of the user (group). If multiple languages are defined the users of the group can select their preferred language from the language picker (at the status menu in the top right). A language always extends another language. For example if you use the English language and you want to make some changes to the translation (e.g. a menu item or notification) you first create a language extending an existing English language. Only the changes to the translation keys are saved. If there is a new version of Cyclos with new or modified keys they will automatically be applied to your local (custom) language. The keys that are customized locally will never be overwritten, but it is possible to go back to the original translation by 'un-customizing' a modified key. You can extend your own languages creating your own language hierarchy. Usually a single level language hierarchy is sufficient.

> Menu: Banking - Vouchers
> Menu: System - Vouchers

A voucher in cyclos has a unique identification 'token' that can consist of a number of digits. The token can be represented as a number or an image such as a QR code (for quick scanning). A voucher represents a certain amount (to be spent at shops). Because of the flexibility of the voucher module there are many use cases. Typical uses of vouchers are gift cards and promotion coupons. A voucher can be printed on paper or a card, it can be downloaded and sent as a pdf file, and it can also be used in digital format at the mobile app and web interface (voucher wallet). The user can spend a voucher at an intake point, for example a shop or a restaurant, who will use the Cyclos mobile app or web interface to redeem the voucher (by either typing in the number or scanning the QR code). A user with a Cyclos account can also send a gift voucher to an external user (without a cyclos account) via email. It is also possible to send multiple vouchers at once with an import file.

A voucher can also be 're-usable', this means a voucher type can be configured to allow 'reloading' or 'top-up' the voucher. The users of these vouchers do not need a cyclos account in order to use the voucher and reload it. There is even a simple voucher page where the user can login with an email and voucher PIN. The page shows the voucher information (e.g. voucher balance) and voucher payments.

Most of the configuration of the Vouchers are done under the menu: System - Voucher. An instruction guide can be found at the Voucher wiki page

> Menu: System - System configuration - Profile fields
> Menu: System - System configuration - Advertisement fields
> Menu: System - System configuration - Record types - select type
> Menu: System - Accounts configuration - Payment fields

Some entities in Cyclos have 'fixed' or 'built-in' fields. For example a user profile has the fixed fields 'email' and 'username', advertisements have a fixed price field, and a payment has a 'description' field. A fixed field does not imply that it is always visible. The admin can change the visibility by setting permissions. Next to the 'fixed' fields Cyclos has also 'custom' fields, which can be created according to the requirements.

The entities that can have custom fields are: user profile, payment, advertisement, record, Contact and Business contact (in user profile) and vouchers.

Some common field data types are: String, Integer (number), list (drop down select) Date, URL, image, file upload etc. Apart from the custom field 'permissions' (that define who has the fields and who can see/edit them) the custom fields have various configurations options, for example if the if the field is required, if it is unique, if it has a default value, and it is also possible to pre-load a dynamic value when the field is being show. Most data types have specific options, for example a String (text) can have a min/max length, a file upload can have allowed file types and max size, etc.

The 'Linked entity' data type allows linking the field to another entity in Cyclos. For example, you can create a profile field that links to another user, or a record field that links to a specific transaction. Linked entities can be very useful when using Cyclos scripting.

Another custom field option that needs some explanation is the category. When creating a field with many values in a select (drop down) box, you might want to put some labels/titles in the list to make it easier for the users to find the value they are looking for. This can be done with 'field categories'. The field categories option will show up in a tab in the custom field configuration page when a data type with multiple values is created. The possible values can be placed into a category from the 'possible values' tab. Dynamic selection. If you put text in the 'Information text' a help icon will show up for the user directly at the right of the field. Clicking on that help icon will open a pop-up window with the information text.

> Menu: System - System configuration - Advertisement categories

Cyclos comes with a default set of advertisement categories, but they can be changed. It is possible to create levels of categories (a maximum of 3). When creating a new category it is possible to create various (sub) categories at once by putting a category per new line. Categories cannot be removed when there are advertisements that use the category. What can be done in this case is to select the 'Active' box. This means that the category won’t show up in the new ad and search ads pages.

> Menu: System - System configuration - Advertisement fields

It is possible to add advertisement fields. Various field types are possible (e.g. text field or date). The fields will appear when adding a new ad and optionally in the advertisement search.

General information about custom fields can be found at this section.

> Menu: System - Groups - Select admin group - User data section -Pending ads
> Menu: System - Products - Select Member product -Advertisement section - Ads require authorization
> Menu: Users -Advertisements - Pending advertisements

As well normal ads as web shop ads (explained below) can require authorization by brokers and/or by admins. When the user submits a new advertisement he will be informed that it needs to be reviewed. When a broker or admin authorized the advertisement will be published and the user (publisher) will receive a notification. When the user wants to change the advertisement the authorization process will start again. When authorizations are enabled for advertisements new status will be automatically available (draft, awaiting authorization, denied, accepted). Admins and brokers can use search filters for the status. Notifications can be sent on each status change.

> Menu: System - User configuration - Member product - Advertisements (section)

Users can have a web shop, through which they can sell products. The web shop can be seen as an enhancement of the advertisements module. Cyclos supports multiple web shops. That means that every user (with appropriate permissions) can have her/his own web shop. Products offered in a web shop can be found by potential buyers through searching the advertisements and through the sellers personal web page. Buyers can add products from the web shop in their shopping cart. When buyers are done shopping they can checkout their shopping carts and pay for the products. The web shop module is a large module and there are various possible configurations, for example sellers can define delivery addresses, and set discounts for certain products. The Web shop management comes with stock management, automatic product numbering and it is possible for the web shop owner to define delivery methods. The Web shop functionality can be defined in permission products, when enabled the feature will appear for users under the 'business' category in the main menu toolbar.

Detailed information about the advertisements and web shop can be found at the online specification page.

> Menu: System - User configuration - Profile fields

It is possible to add custom profile fields. Various field types are possible (e.g. text field or date). The fields have to be enabled in the user product.

General information about custom fields can be found at this section.

> Menu: System - System configuration - Custom image categories
> Menu: System - Content management - Custom images

An administrator can upload images (pictures) that can be used in the content management (e.g. header, pages, messages). Before uploading an image a image category needs to be created.

> Menu: System - System configuration - Record types
> Menu: System - System configuration - Shared record fields
> Menu: Reports & data - System records
> Menu: Users -User records - Record name
> View user profile - User information- User record

Records are a powerful feature that permits storing data in a structured way and being able to search and access specific values (the custom fields belonging to a record). For any need to store data for users or general system data, and be able to edit and search it, records can be used. A simple example of a user record is a remark. A remark is a user record with just one text field that can be modified by users (e.g. admins and brokers). An example of a more complex user record is a credit analysis form that will return a credit score overview when submitted.

There are two types of records; 'user' records, that are always bound to a user (member, broker or admin) and 'system' records, that do not have a related user. A record consists basically of a group of custom fields. You can define one or more custom fields for a record type. If you want to share a specific field among various records you can create a shared record field first and add it to the record. Records will have mostly their own (not shared) fields. These can be added directly from within a record. In the permission products an administrator can define who will 'have' user records and who has permissions to add/modify/view/delete records. Each role (member, broker, admin) can have its own access permission related to the same record type. Members can only be given permissions to access their own records (no system records or records of other users). It is possible to define fine grained permissions for records, that means that users (admins, brokers and members) can be given specific permissions for (custom) fields of a record type that they can view or manage.

A record will always show a creation date, and the user that updated the record. You can allow just one (single) instance of a record, which usually will be editable, or multiple instances, that can be shown in a list. User records can be accessed from the User management menu or directly from the user profile page. System records can be accessed from the 'Reports & Data' menu. Records can be displayed in different layout formats (e.g. single page, normal list, tiled list). Fields can be shown in columns to improve visibility, and it is possible to display them in a view/edit mode (just as the user profile), or open them directly in edit mode.
It is possible to create sections with titles for a record. This will be useful for the visibility for records that contain many fields. It is also possible to show a record as a quick access icon in the dashboard page. A custom icon can be uploaded for a record type.

Records can also be very useful in the combination with the scripting module (see Cyclos scripting). With the scripting module you can access any internal entity in Cyclos (e.g. user, address, payment, authorization, reference etc.). When developing custom operations it is likely that you want to store and use custom entities with their values. It is possible to create specific record types and custom fields and use them by the scripts. The record types can be of the type 'system' or 'user' depending on the requirements. Giving permissions to the record you can also search on them or export them if necessary. Detailed information about the user records can be found in the online specification page.

> Menu: System - User configuration - Agreements
> Menu:System - User configuration - Member product - Agreements
> View user profile - Accepted agreements

An agreement is a text that can be shown at the registration page and the login page, with a select box that the user can check before submitting. There are required and optional agreements. Upon registration, users will have to select the required agreements, and can optionally select the non obligatory agreements. All agreements have a clickable link that opens the agreement text in the pop-up window.

Agreements are created by administrators and assigned to products. If an agreement text is changed by an administrator a new version of the agreement will be automatically created when a user user accepts the agreement (until this happens the text can be altered without creating a new agreement version). Version changes will not force the user to accept an existing agreements again. So if you want the user to accept a new agreement you will have to create a new one and assign it to a user product. When a new agreement is added at a later stage, existing users will be asked to accept the agreement upon the first login. This is also the case for existing users that are assigned new/other products with different agreements.

Older agreement versions can still be seen in read only mode by the administration. There is a full history of accepted agreements (per user) and the version that was accepted. For end users (non admins) an overview page is available from the personal menu in Cyclos. Users can see the agreements with historical data (agreement acceptance date) and can select or unselect the optional agreements.

An agreement extension point is available. This makes it very easy to add business rules upon agreement status changes. For example, when a specific optional agreement is accepted an individual product could be assigned automatically to a user.

> Menu: System - User configuration - Privacy control
> Manage user: - Privacy settings

Privacy control in Cyclos is a mechanism that allows users to specify what personal data can be accessed by which departments. The privacy control feature is added for compliance with regulations such as GDPR.

An administrator can define 'privacy admin groups', for example a group called 'accounting' or a 'commercial' group. The users can select which administration group is allowed access to their personal data. There can be 'required' privacy groups that the user cannot unselect.

More information about privacy control can be found in the privacy wiki page.

> Menu: System - System configuration - Messages categories
> Menu: Users - Messages - Search / New message

Message categories are used to organize the communication between members and administrators. For example if a member wants to send a message to an administrator he/she has to select a category. This helps to define the right person to answer the question. The categories are created by the administrator. In the member product is defined what message categories are available to the users, and in an administrator group permissions you can define what messages (categories) an administrator can manage.

> Menu: System - System configuration - User identification methods
> Menu: Users - Tokens

The user identification methods define how users are identified and displayed in Cyclos. Many operations in Cyclos involve user identification. For example the identifier required at the login page (e.g. login name or email), the identifiers you can use for searching other users, and identifying the user you want to pay. There are four types of user identification methods: built-in identifiers, custom profile fields, tokens, and access clients.

The first type (built-in) identification methods are: login name, e-mail, mobile phone and account number. In order to use an email as an identifier it will need to be set as 'unique' (no duplicates allowed) in the configuration. If you want to use an account number (instead of a general account name) it can also be defined in the configuration.

The second type of user identification methods are custom profile fields. Using custom fields as identifiers will work much in the same way as the hard coded (built-in) identifiers.

The third type of user identification methods are the 'tokens'. A token is typically an ID stored on a physical medium like a card. The token ID can be a plain number (string), Bar/QR code or NFC Id. Tokens can also have format masks and various validation options like activation and expiration period, max tokens per user etc. Tokens (e.g. cards) can be created one by one in Cyclos, and for bulk token creation it is possible to use the import tokens feature. When a user has the create users permission in the mobile app he can personalize a NFC card directly in the user creation flow. Once a token is assigned to a user there are various options available like changing the status to un/block, un-assigning the card, changing the expiry date etc.

The fourth type of user identification methods are the 'access clients'. These are used to enable and manage external (software) access to Cyclos. An access client is basically a secret unique long key. The main advantage of using an access client is that the software does not have to send a identifier/password combination with each request. An access client is always owned by a user. So a user that has the permission to have an access client can use third party software to connect to Cyclos using his access client. So after the access client is created go to the product of a user and enable the access client for him.

The POS mode of the Mobile App for Cyclos, which is also an 'external' application, uses an access client. Users (shops) that will enable their Mobile phone for POS payments will need to create and activate an access client of type 'Mobile POS'. Once the shop has activated the access client the POS mode does not require user/password input at startup. Another advantage of using access clients for POS devices is that a user can manage his own devices, for example (un)blocking them and retrieving information about payments done at a specific POS. The Cyclos wiki has a Quick steps page for setting up POS, Cards and Access clients in Cyclos.

Access clients serve also very well for dedicated and secure access to third party software services. For these types of uses the access client type will not be available for various users (as with the mobile POS example) but a dedicated product can be assigned to a dedicated user. Optionally a dedicated Channel can be configured for third party access. The third party software will communicate with Cyclos via web services. A dedicated access client for third party software will usually implement a white list of allowed IP addresses and some additional restrictions can be configured.

A good example of a third party access client is the WordPress plugin that has been made available. This plugin allows users to login in Cyclos directly via a Wordpress website. For more information see: wordpress.org/plugins/cyclos/

Note: When a third party supports OpenID Connect - OAuth2 it can be preferable to use this access method, which is also supported by Cyclos.

Per channel you can specify what user identifications methods are allowed and you can also set a default identification method. It is possible to 'refine' the possible user identification methods per transaction type so that you can have for example various card types with different rules. You can define multiple identifiers per function. For example, you can allow users to login either with their login name, email or phone number. Be aware that choosing the identification methods involves privacy and security. It can be handy to allow users to login with email or phone number, but for security reasons you might not want users to login using identifiers that are visible by other users in the system. For a highly secure system you might consider a private identifier like a login name (set to be not visible for other users). Various other security settings exist such as virtual keyboard, password renewal policies and authorizations etc.

> Menu: System - Users - Management - IP addresses

The IP address page will show a list of blocked IP addresses. An IP can be blocked for many reasons, but most commonly it is because the maximum amount of wrong password / username attempts was exceeded. These blocked IP’s will have the 'temporarily blocked' status, and they will disappear from the list when the blocked period expires. It is possible to manually unblock IP’s, and an IP address can also be permanently blocked or allowed. Allowing IP never to be 'always allowed' is something that needs to be used with care because it will override all other IP rules, for example those in the channels (IP whitelists).
It is also important to be aware that the IP addresses feature is global and can only be managed by a global administrator. The list is the same among all networks. It can be shown at network level but this is just for convenience.

The IP address details page shows a marker on a (google) map of the access. For this to work IP geolocation needs to be configured. A configuration example can be found in the reference guide

> Menu: System - Users - Management - Invite users
> Menu: System - Products - Select member product - General section - Invite users

It is possible to give the users the option to invite other (new) users. When this option is enabled an 'invite user' option will appear in the user section. The user fills in an email to the user they want to invite. The invitee will receive an email with a link to explore Cyclos.

The invite text is defined by the administration (MESSAGING.MESSAGES.inviteMessage.body.admin).

When the invited user registers the user won’t be asked to confirm the email (if this is configured) as the user has already confirmed by selecting the registration invitation link in the email.

A user that sent an invitation can search for invited users that have successfully registered themselves at the user search page (advanced search - check: 'invited by me').

> Menu: System - System configuration - Identity providers

Cyclos supports the OpenID Connect standard, which allows users logging into Cyclos with credentials (e.g. userID/password) of other platforms such as Google or Facebook. OpenID connect can be enabled for the registration of new users in Cyclos. Before the registration process the user can select the external identity provider and authenticate.
User data from the third party platform (e.g. email and address) can be copied automatically to the Cyclos registration form and saved to the user profile. This can be very convenient for the quick sign-up of new users.

Cyclos can also act as an OpenID Connect server. With this service third party software can allow users to login into their system with Cyclos credentials. More information can be found at the wiki page:

Wiki4 - External identity providers

> Menu: System - System configuration - Tools

The Cyclos scripting module provides an integration layer that allows connecting from Cyclos to third party software, as well executing custom tasks and operations within Cyclos self. The scripting engine can access the full Cyclos services layer which makes it a powerful feature. For security reasons only global administrators can add scripts. Network administrators can be given permissions to bound the scripts to elements such as extension points (eg. payments, user profile, voucher), custom validations (fields), custom calculations (account fees, transaction fees), custom operations, custom web-services, scheduled tasks and wizards.

It is also possible to add or modify features with service interceptors. This is a script type that allows running a script before or after any internal Cyclos method. For Cyclos elements for which dedicated extension points exist (e.g. payment, profile), the extension point script is the preferred method to add functionality using scripts.

On each script details page there is a button 'Get code for debugging'. This will download a zip file with documentation on how to run the code locally and how to debug it.

Detailed information about all scripting types and examples can be found in the scripting section in the Cyclos reference guide.

> Menu: System - System configuration - Tools - Custom operations

Custom operations allow creating custom built features in Cyclos with scripting (see directly above). Once custom operations are created they can be assigned via the products (permissions). They can be made available to users, brokers and admins and can be placed under the main menus (e.g. banking, users), or they can be placed within a custom menu (which can be created in the Content management section). In the mobile app they will show up as an action button at the home page. Instead of accessing the operations via the Cyclos menu or Mobile home page, the custom operations can also be run from a Cyclos entity page. For example from within a user profile, a record, a payment, an advertisement, and a contact. Custom operations that are run from within a Cyclos entity page will have access to the context and variables of that entity. If you need new (custom) entities you can use Records.

Custom operations will automatically be part of the Cyclos API, meaning you can give access permissions to third party applications.

A custom operation will typically show an input form with a submit button. It can return a details page, or first show a list where the user has to pick an item, which will open the details page. Other flows are also possible. Custom operations can have 'nested' or 'sub' operations. For example in a details page returned by a custom operation you can show one or more custom operations. These operations can show up according to the permissions, and it is also possible to show custom operations based on logic and input data from the context (e.g. specific values of a profile field of the user running the operation, or values of the data that is shown).

A list of all possible custom operation types can be found at the cyclos reference guide.

For more complex operations it can be better to use wizards, that allow splitting operations in various steps.

> Menu: System - Tools - Imports
> Menu: Banking - Tools -Import payments

The import functionality can import the following (user) information such as users, payments, advertisements, references etc.

The information can be imported by uploading a file. The import feature works with steps. When the import is done there is an overview page with the status and other useful information about the import. If the import button is not visible you need to give the administrators group the permission for this.

There are two typical uses for the import of transactions and for the ease of use the import transaction feature has been split. The first is the migration of users and transactions from one system to Cyclos. This is typically a one time task and is available under System - Tools. Another typical use is the import of transactions that need to generate transactions in Cyclos, for example user deposits in conventional currency. The latter function is more operational and is available under the Banking menu.

Detailed information about imports can be found in the online specification page.

> Menu: System - System configuration - Export formats

Various search results lists in Cyclos have a download(export) function. Typical exports are: transactions, users, advertisements, webshop orders, vouchers etc.

The built-in formats are csv (comma separated), PDF and excel (xlsx). In some cases custom export formats are required. For example to provide compatibility with third party software products that have their own formats, such as bookkeeping software. In this case custom export formats can be created. First a script of type 'export format' will need to be created. The custom format will be added to the existing export formats.

The custom export format does not just allow exporting with a different format, it is also possible (with the script) to modify or extend the export. For example additional columns/values can be added to an export.

Detailed information about export formats can be found at the cyclos reference guide.

> Menu: System - System configuration - License

Cyclos needs a valid license key in order to run. There are three types of licenses: Free, Social and Commercial.

Selecting 'Update now' will update the license. Commercial users can update the license offline.

For more information about licenses view the Cyclos license page

The license will be visible at the bottom of the user and admin manuals.

Note: The license option is only available when logged in as a global administrator.

> Menu: System - Products - Select Member product - Account section - Manage tickets
> Menu: System - Products - SelectMember product - Account section - Receive / Make payment (tickets)
> Menu (User): Banking > payments > tickets

The ticket system provides a secure method for cyclos payments done via third party channels, for example a payment at a third party webshop. The ticketing system assures that the shop and the payer cannot alter payment data after it has been submitted for confirmation. The ticket system also prevents 'man in the middle' payment data alteration. There are many uses for the tickets. Two common uses are explained directly below.

> Menu: System - Configuration > Section: New front-end
> Menu: Content - Static content / Menus and Pages / Banners /Themes

Cyclos has two built-in front-ends, the classic front-end based on GWT (Google Web Tools) and a more customizable and modern front-end based on the angular and bootstrap frameworks. The new front-end is responsive meaning it displays (resizes) well with different screen sizes and resolutions (from larger monitors to smartphones).

The new front-end is intended for end-users and some administration functions are not available. The GWT based front-end has all available Cyclos features. Which front-end will be used can be defined in a configuration (that can be bound to a group).

If the new front-end is defined for a configuration that is bound to an administrator group the users (admins) of these groups can always switch between the new and classic front-end.

The customization of both front-ends can be done from within Cyclos. The new front-end is based on an open source project and uses the RESTful API and can be completely customized.

Detailed information about the new front-end can be found at this wiki page.

> Menu: Content - Content management - Documents
> Menu:System - System configuration- Document categories

An administrator can upload static and dynamic documents and assign them to users or to groups. A document can be assigned to one user (individual document) or to a group of users (shared document). A 'static' document can be any file, for example a picture or pdf file. It can be either a shared or individual document. A 'dynamic' document can only be a shared document. It is a way to have users fill in forms in a predefined format and include input data and user data such as profile fields. A typical use of a dynamic document is a loan contract that requires user input and user data, and which the user will print and possibly sign. When a user selects a dynamic document a page will be shown. This page can include images, (rich) text, profile fields (of the user), variables such as date and time, and optionally input fields that the user needs to fill in before submitting. After a user submits the form a result page will be shown with all the data included and formatted. A print button will be shown so that the user can print the document.

If you want to enable 'shared' documents you will have to create a document category first: System - System configuration - Document categories. Before documents can be added and viewed you need to set the permissions: admin group - User data - Individual documents/ Shared documents). If you want the member to be able to see the documents you will have to give permissions in the user product: Individual documents, View or Manage shared documents with categories.

> Menu: Content - Content management - Custom images
> Menu: System - System configuration - Custom image categories

An administrator can upload custom images (pictures) that can be used in other content management items (e.g. pages, footer, messages). Before uploading an image an image category needs to be created. In order for an admin to use an image category you will give the permissions: System - User configuration - Groups (admin) - Content management - View/Manage images with categories)

> Menu: Content - Content management - Custom svg icons

Cyclos has various built-in SVG icons, for example for the menus, quick access operations, and other locations where small images are helpful to explain the function. For the icons Cyclos uses SVG images. The advantage of (vector based) SVG images is that they are small and they resize without losing quality.

Cyclos has built-in SVG images (e.g. menus, dashboard icons) and for some functions it is possible to select an icon from a set of icons (eg. custom operation, wizard step, user record). If the set of icons is not sufficient it is possible to upload custom SVG icons. Once uploaded they will appear in the icon picker in the configuration page of the function that uses icons (e.g. custom operation or record type). It is possible to set the color of the icon, but usually you want it to adapt its color to the other (built-in) icons. This can be done by specifying the color as follows: fill="currentColor"

> Menu: Content - Content management - Application translation

The application translation menu item appears as soon as a local language is defined (see language section ). The application translation consists of the entire translation of Cyclos (menus, labels, titles) and all internal messages, emails, notifications. You can search on the original translation and the current translation (which includes your customized keys). By selecting a key from the list you can customize the translation. You can import and export customized keys using the buttons at the search window.

For a user of an admin (group) to be able to view/customize translations you need to set the permissions in: System - User configuration - Groups - Permissions - Content management - Application translation.

If an admin can manage more than one translation a list will be shown first.

> Menu: Content - Content management - Data translation

As explained in the section application translation, the 'built-in' Cyclos translations keys like menus items, form labels, notifications and other texts are defined in the application translation. Cyclos also has many 'dynamic' (non built-in) elements that do not exist in the Cyclos package but are created by administrators when configuring the system. Some examples of dynamic entities are: accounts, transactions, fees, message categories etc. For systems where users with different languages access the same Cyclos entities (e.g. accounts) there must be a way to translate those entries into multiple languages. This way each user will see for example the same account in their own language. The translation of those dynamic entities can be done with the 'Data translation' feature. It would be rather cumbersome to manage multiple translations of dynamic entities in the entities forms self. Therefore the Data translation feature centralizes and categorizes the translation of the dynamic entities from a single page (Content - Content management - Data translation)

> Menu: Content - Content management - Static content

Cyclos has various 'static' or 'built-in' pages that can be customized. For example the public home (guests) page, mobile pages, headers and footers, the ticket page, email template and the help pages. When selecting the pages from the 'Static content' a rich text editor will open. You can insert an image by selecting the image icon (third from the right). It is possible to insert html format by selecting the html option of the editor. You can always revert to the original page by stopping customizing the page.

There are many notifications that Cyclos can send via email. For example, a registration confirmation email, an email when receiving a payment, or an advertisement match. With the use of email templates it is not necessary to change the notifications, but a single email template can be used to define a general layout for all notifications. The template has a rich text editor and you can include variables. The template feature has a preview so that you can directly see how the message will look.

Detailed information about the static content can be found at the online specification page.

> Menu: Content - Content management - Main web menu & pages

It is possible to add new menus items and submenus that will open content pages or external pages (URL’s). When creating a sub menu and content you can choose to place it directly in the menu bar or under an existing menu (group). A content page can also be a floating page, meaning it does not belong to a menu but it can be linked to from another content page. It is possible to define in the page who can view it (e.g. guests, logged users) and the location where it is shown.

Detailed information about the menu and pages can be found at the online specification page.

> Menu: Content - Content management - Banners

Banners can be added at the left and/or right of the main Cyclos windows (classic interface only). When putting more than the maximum number of banners (defined in 'Configuration - Display - Maximum banners) the banners will rotate. The rotating time can also be set in the Display section of the configuration. The content of the banners can be managed with a rich text editor in the same way as the content pages in the menu section (see above).

Detailed information about the banners can be found at the online specification page.

> Menu: Content - Content management

The complete look and feel of the mobile app can be changed in Cyclos.
New mobile pages can be created. An icon can be selected when creating a new page or custom operation. The pages will be shown after clicking on the shortcut icon in the mobile app home page.

The content and layout of a mobile page (including the title and icon) can be created and edited in: Content > Content management > Mobile pages.
The login header, login footer, mobile help and mobile POS help can be customized through: Content > Content management > Static content

The mobile theme can also be customized. The colors can be customized using a color picker and even the CSS of the mobile app can be completely changed. First create a new mobile theme, and second apply the theme for mobile devices: Content > Content management > Themes.

> Menu: Content - Content management - SMS texts
> Menu:System - Configurations - Channels - SMS Channel - SMS operations

When SMS is activated it is possible to define SMS info texts. These are texts that have an alias defined. The text will be returned when a user sends an alias in an SMS to the system SMS phone number (e.g. an SMS with the word/alias 'promotion' could send the last promotion defined by a cyclos admin).

More information about the SMS module can be found at the SMS quick steps wiki.

> Menu: Content - Content management - Logos

When you upload new logos from this page the existing logos will be replaced automatically. If you want to change the top section (header) this can be done in the content section.

Detailed information about the logos can be found at the online specification page.

> Menu: Content - Content management - Themes

A theme defines the layout (e.g. colors, menu bar size, font style) and system images (e.g. quick access and remove icons). There are types of themes for; Web (classic and new front-end), the Mobile app and the ticket page. When saving a theme it will be directly applied. Any network in the system has a theme applied. This can be a theme inherited from a higher level, or a theme managed directly at network level. Cyclos comes with various 'built-in' themes and it is possible to create new themes as well.

There are three levels of customizing a theme. The first (easiest) level is done with a color picker. This allows you to create a new theme in a few minutes. The second level is done by changing common theme elements by predefined Sass variables. Normally variables are used to group layout items that logically share the same value (e.g. all window borders). The third customization allows you to customize the entire CSS file. When creating a new theme you have the option to create an empty one, or extend an existing theme. It is also possible to import and export a theme.

Detailed information about themes can be found in the online specification page.

> Menu: Content - Content management - Voucher templates

With voucher templates you can create templates for vouchers with layout, images and dynamic content. A new template will always extend an existing one (built-in or custom) but this is just for convenience (the entire layout/content can be changed). The voucher templates can be previewed directly from the voucher page (download as PDF) and it is possible to preview the voucher in a browser so that you can modify/preview the layout on the fly with a browser tool such as Chrome DevTools or Firebug.
When a voucher template is saved you can select it in one or more voucher types (System - Vouchers - Voucher types).

Details about pdf templates can be found at the online specification page.
Information about vouchers in general (configuration and use cases) can be found at the voucher section.

> Menu: Reports - Reports - System information

The system information gives a quick overview of the system status (Cyclos and hosting environment), and it contains actions for system administrators. A system information can be downloaded as a single pdf file (for troubleshooting). The page has the following tabs/pages:

Note: The upgrade process will also check if the database schema (structure) is intact. If this is not the case a system error with the necessary information how to proceed will be generated.

> Menu: Reports - Reports - System reports

At the system reports page you can retrieve overviews with the most important data such as the number of users, advertisements, trade, and so on. It will basically show data over a period, though some of the presented data is point data, which means that it can logically only be given on a certain point in time. Most statistics are self explanatory. Options that might need some explanation are described here below:

> Menu: Reports - Alerts & Logs - System alerts

The system alerts will show alerts related to the entire system such as: application started, scheduled task run, new version of translation file uploaded.

Note1: A notification can be generated on system alerts, this can be configured in Menu: Personal - Preferences - Notifications.

Note2: If a system alert contains more than 200 characters the text will be broken and an icon is shown. Clicking on this icon will open a pop-up with the complete text.

> Menu: Reports - Alerts & Logs - User alerts

Typical user alerts are: failed password attempts, new pending user, expired loan etc. Clicking on a user alert in the list will open the profile of the user.

Note: A notification can be generated on user alerts, this can be configured in Menu: Personal - Preferences - Notifications.

> Menu: Reports - Alerts & Logs- Error logs

Errors that occur in Cyclos will show up in this list. An error is typically a software issue, due to a problem with Cyclos scripting or in the Cyclos code itself.

Note: In case of a possible issue with the Cyclos code a full report (including the last 10 error logs) can be downloaded at: Reports - Reports - System information - Download full report.

> Menu: Reports - Reports - Alerts & Logs - Configuration logs

A 'history log' in Cyclos is basically a page with a complete history of all the changes that are made to a Cyclos entity. History logs are available at two places. It is shown in the entity self under a tab called 'History'. This can be for example the user profile or the product details page, and there is also central history search (in the Reports section - Alerts & Logs).

The history page will show a list with all changes that were made with the following information: the old and the new value, the username and IP address of the user that performed the change, the timestamp of the change and the channel through which the change was made.

The 'configuration' logs contain changes to system configuration entities such as; product, group, channel etc.

Note: Besides the history logging, Cyclos also logs all operations and changes to the Cyclos log files (or to a dedicated logging database depending on the configuration).

> Menu: Reports - Reports - Alerts & Logs - User logs

User logs contain any changes made to user entities such as; profile, record, advertisement and token. The User logs search has many search filters and offers interesting use cases. It allows for example monitoring all changes done by a specific admin or broker within a specific period. The central history search also has a user filter, which allows searching for changes in different user entities (e.g. profile, address, phone, token, advertisement) of the same user in one single search.

> Menu: Reports - Reports - Alerts & Logs - Access logs _> User management page: User information - Access logs

The access log page logs every successful login via every channel. The general search will show all access logs in the system (but it is possible to filter by user). From the user management page the access log of the specific user can be shown.

The access log shows a marker on a (google) map of the access. For this to work IP geolocation needs to be configured. A configuration example can be found in the reference guide

> Menu: Reports - SMS messages overview - Inbound SMS / OutboundSMS

The SMS message overview pages will show all inbound/outbound SMS messages. It is possible to search by status, period and phone number.