Help - administration

General

Help - HOW TO

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 showed. The location is in italic and has a > sign in front.
For the more complex configurations instruction video's are made and published at this page. New features might not be covered yet in the video's. We will add video's along the way. Another helpful resource is the cyclos feature list.

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 video's.

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 the local preferences (Personal > Preferences > Dashboard actions)
The ‘quick search’ (at the top right) can be used to search quickly for 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.

Personal settings

Menu: Personal

At this section you can change personal settings like changing your password, update your profile, and view notifications. In the ‘configuration’ section you can define what dashboard actions will show up at the entry (home) page, and the notifications that can be send to your Cyclos notifications inbox and/or your e-mail address.

User management

Most administrator actions about users are done from the user profile. These user actions generally are self explanatory. The actions that need additional explanation are described further in this help section.

Search users & register user

Quick search: Search Users Menu: Users - Management Dash board action: Search Users Dash board 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.

My contacts

Menu: Users > Management > My contacts

Here you can manage (add & remove) contacts. Selecting a contact of the contact list will bring you directly to the user profile of the contact. From the profile page you can perform user actions related to the user (e.g. make payment or send message).

Manage company contacts

Menu: Users - Management - User profile Member product: General > Maximum additional contact information Admin group permissions: User management > Manage additional 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 added additional company contacts. The contacts will be show in the view profile page (at the bottom) and the contacts can be managed from the edit profile page.

View connected users

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.

Change profile of user

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, additional contact information and profile pictures.

Make a payment to user

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. De pending 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 chose one. Most systems have only one possible payment type defined. What means no payment options will be shown.

Change credit limit of user

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 what 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'. A 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.

Change group of user

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, what means the user could get different features and permissions. More information about groups can be viewed at: manage groups.

Change user status (activate, block, disable, remove)

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

As an administrator you can block or disable users temporary. A user with the 'blocked' status cannot login via any access channel but will be active in the system, what 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.

Manage user passwords

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 send by e-mail.

Write user comment (remark)

View user profile - User information - Remarks Menu: Users - User records - Remarks

Administrators can insert remarks (comments) for a user from user profile (link 'Remarks') and view a history of remarks for that specific user. From the menu administrators can search for Remarks given to all users.
Note: The remark is a 'user record' defined in the default database that comes with Cyclos. Records is a powerful feature in Cyclos that allows to store and retrieve data in an structured way. A remark is a very simple example of a user record. More information about user and system records can be found here.

Assign product to user

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.

Manage access channels of user

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.

Manage credit/debit cards of user

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.

Assign broker to user

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.

Upload user document

View user profile - User information - Documents

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

View configuration of user

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.

Manage advertisements of user

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).

Manage references of user

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).

Send message to users

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 and e-mail are supported. A history of sent and and received messages is available under the Menu: Users - Messages - Search Messages. When selecting a mailing form the mailing list it will give information about the mailing (e.g. number of successfully sent / failed messages).

Payments overview

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.

User balances overview

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 list of users with their account balances. 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 with 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 what 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.

Manage account limits

Menu: Banking - General overviews - Account limits

Here you can have a quick overview about account limits. The latest (most recent) limit changes are listed on top. Entering a account limit detail the limits can be changed. The same page has also a log with the history of account limit changes.

Bulk actions

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 chose 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 a 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).

Manage notification settings of user

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.

History change log (profile, records)

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

All changes to profiles and record 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 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 show the the new and the old value, the date/time stamp and the IP address of the user that changed the value.

Note: Cyclos has also system level logging. Any operation in Cyclos is logged into a log file. The system wide logging is defined in the configuration.

Account configuration

Currencies

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.

Accounts

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 be either 'limited', what means it can be given a max negative and positive balance, or 'unlimited', what means it can go indefinitely negative or positive.

- Account number
Accounts can be identified by either a general account name, or a individual account number.
The account number format can be defined in the Configuration (section account number generation).

Account fees

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

Account fees are payments from 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.

Transfer types

Menu: System - Accounts configuration - Account types - 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'. The transfer type defines the origin and the destination account type of the payment. 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. charge back time in the transfer type. When a charge back 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.

Transfer fees

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

A transfer fee allows to charge a fee automatically when a specific transaction occurs. For this reason a transaction fee is configured 'within' a transfer. 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 fees 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 user can later filter on fee transfers. Fees can also be charged within another currency.

Payment fields

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.

Payment status

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) what 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 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 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'.

Payment filters

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".

Payment authorizations

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 check box "requires authorization" in the transfer type. Once the 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 (reciever 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 in 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.
Detailed information about authorizations and roles can be found in the online specification page.

Payment qualifications (feedback)

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 informations - 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 feedbacks that are given to other users. A user can disable payment feedbacks 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).

Scheduled payments

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 multiple 'installments'. Upon each installment date the payment is debited from the payer account. A user or system administrator can see an overview of the outgoing scheduled payments, and optionally of all incoming scheduled payments as well. Depending on the configuration a scheduled payment can be canceled, blocked, unblocked and processed in advance.

Recurring payments

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

A transfer type can be configured to allow 'recurring'. Like a scheduled payment, a recurring is a transfer which is to happen in the future, but is already agreed upon and scheduled. with the difference that recurring payments will not happen at specific days but at an interval of a period (e.g. each week, month, year). The users can set the first recurring date can be set and number of occurrences (a fixed number or indefinitely).

Payment requests

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 re-payment will have to be paid for the whole amount or if it can be payed 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 by and SMS. 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).

Pay external (non registered) user

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.

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.

Easy invoicing

Business and users can generate QR codes and payment URL's that contain the receiver, amount and description. The QR codes and URL's can be printed (on an invoice) or send 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 https://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.

System configuration

Networks

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 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 projects (networks) 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 informations for the ‘umbrella’ organization.

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

Network wizard

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

Setting up a system from scratch requires a 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.

Groups

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 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 ). It is not possible to add products to administration groups. The administration permissions are defined directly in the group (permissions tab).

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.

Products

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 a 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'.

- Accessibility and Visibility
The permissions in the 'Accessibility and visibility of groups and users' section defines how users can see each other, and how they can operate with each other. Cyclos is very flexible (configurable) in the way users can search for each other and view users profile fields and other user information such as addresses, phones and account numbers.
The option 'Accessible user groups' is the basic permission that allow users to inter-operate. After defining the 'Accessible user groups' the operations still need to be configured. This can be for example enabling specific payments, or giving the permission for users to insert advertisements. Be aware that the 'Accessible user groups' permission does not necessarily mean that users can see each other. For example, when userA has the accessibility permissions regarding to the group of userB, but no visibility permissions, he could still receive a payment or a reference from userB. What will happen is that the incoming payment or reference will show just the identifier of userB (e.g.full name or login name) but the identifier will not show a link to the profile of userB (for this visibility permission is needed). The type of identifier that is shown is defined in the active configuration that is bound to the group of userB. In a typical system users can search for each other and view each others profile. This can be defined in the 'Search users on groups' and 'Search users on groups' options. There are basically three ways to find and see other users, from the user search page, directory map and quick search, via links in entities (e.g payment details or reference) and via auto-complete user form fields, which can be found for example in the payment form (if enabled as identification method). With the 'Profile fields of other users' you can refine what specific profile fields users can see of each other. Usually users can see their own profile field, but in some cases you might want a field only be visible and editable by a broker or administrator. Further you can define where the fields show up, for example at the registration form, in the user and advertisement search etc. Optionally you can give the user permissions to hide the field for other users (this is common with fields like mobile phone nr).

If needed the user search function can be switched of (by setting the option 'Search users on groups' to 'none'). Most banking systems for example do not have the option the search for other users because of privacy reasons. Of course, if you switch the search user feature off users still would need to be able to find other users, for example to perform a payment. This can still be allowed but only by entering a complete identifier, for example a full email, account number or a specific (unique) custom field created for this purpose. At the payment confirmation the full user name of the destination (payment receiver) will be shown. And after the payment the user can be added from the contact list.

The 'View user directory (map) on groups' option allows users to search for other users via a Map. Information about the Map can be viewed at the configurations help section (see 'Maps & Directory').
The Accessibility and Visibility settings consist of 'radio selects', these are basically group selects and have the options: None, Own group, Own group-set, Specific groups and All (accessible) groups. The options are self explanatory. The 'own' group and group-set options serve to keep the configuration simple. In case of a system configuration where users of various groups are allowed to see the users of their own group or group-set, and only in specific cases users of other groups, you could create one product for each group and select the specific group. But a single product with the permissions own group or group-set might be enough. Specific (inter-group) permissions can be handled in separated products what would make the configuration more clear.

- General
The 'General' section of the product page defines elements that a user can have and see, for example a tokens (cards), user records, documents etc. The section contains also actions that do not fall in the scope of account permissions,for example accepting agreements and creating operators.
(The account permissions and rules are all defined in the Accounts section, described directly below).

- Accounts
The account section contains all the permissions related to payments or other entities related to payments such as vouchers, authorizations and status flows. A product can contain only one account. Of course it is possible to create different products with different accounts and assign them to the same group.
Broker and administrators do not have accounts, but can be given permission to manage other accounts (in the product section: User accounts).

- User management / User data
This sections, which are only visible in administrator and broker products, deal with the management of other users. In the User management section you can give the broker or administrator the permission to perform user operations, for example disabling a user. In the User data section administrators can access user data such as profiles and advertisements, and perform operations such as making a payment on behalf of a user.

- Broker permissions
There are two types of products. One for normal members and a specific product type for brokers. A broker (user with a broker product) can register new users and have some level of access and control over these users. The broker product defines in which groups the broker can create users and what permissions the broker has over its users. A user can be assigned to more than one broker but there will always be one 'main' broker. The main broker will typically have more permissions over their users such as receiving a commission. The name "broker" does not explain the function well because the broker function can be used for different purposes. For example loan agents of micro-finance systems where the agents can register new members and retrieve information about the loan status of the members. Broker products contain mostly broker permissions, and cannot have an own account and neither contains the accessibility section. So typically you will create a broker group and assign a member and a broker product to the group.

Operators

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 an own login name and profile fields, and they can have their own cards and mobile phones, but do not have an 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 the connected users - operators menu item).

Configurations

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

Most settings in Cyclos can are defined in a 'configuration' (there are no 'system wide' settings in Cyclos4). 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 from a hierarchical configuration 'tree'. A lower level configuration will always inherited the ‘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.

- User data
This section deals with the login name format and registration rules. When one or more options at the 'validate email' is checked the user will receive an automatic mail with a confirmation link. All other settings should be self explanatory.

- Localization
This section deals with formats such as dates, numbers and distances. When changing any language setting please have a thorough read through the language section of this manual.

- Addresses & Phones
Addresses and phones are also defined in configuration. The options should be self explanatory. The validation checks for phones and addresses are derived automatically from the localization section.

- Display
The display section contains settings that deal with how elements are show to the users. Before modifying this it would be good to review the Configuration wiki (see Display section).

- Maps & Directory
Cyclos can show a (Google) map when searching for users or advertisements. The map will have clickable markers that open a information box with the user information. The map can show up at a profile, at the main user search, the advertisements search and the business directory page. The map option in the main user search and advertisement pages will show the user according to the visibility defined in the member product. The business directory page will show the users from the groups defined in the product setting "View user directory (map) on groups". When the business directory search is enabled in the product it will also show up as an option in the mobile app. The mobile app will show the search result based on the Geo (GPS) location of the mobile phone.
It is possible to define a multi-option profile field that can be used to refine the searches. The field will show up as search filter in both the Web directory as the Directory in the mobile phone app. A typical search field would be a list of categories where people can spend their units such as: Restaurants, cash-in points, supermarkets etc. The multi-option profile field can be selected in the product: Profile fields of other users - Column: Map filter.
Note: As of october 12 2016 the Google Map services (API) requires a key. The Google API credentials can be specified in the configuration.

- Account number generation
Similar to a transfer number, an account number can be generated by applying a mask. If you want to more complex account number formats and validation such as Swift or IBAN you can use a account number generation script. When account numbers are enabled in systems that have already accounts the existing accounts won't receive an account number. This can be solved by running custom operation that creates account numbers for existing accounts.
Information about customized account number generation can be found in the online specification page.

- Email and SMS outbound
For a detailed description on email and SMS outbound configuration please view the online specification page and the SMS quick steps wiki.

- Data visible to guests
Guests are users that are not logged into Cyclos but visiting 'public' Cyclos pages such as the public home page, content pages, login page and the registration page. You can define in this section in what groups users can register themselves. Usually you would enable email validation when users can register themselves (option 'Validate e-mail on'). If you don't want users to be directly active after they have registered you could create an initial group for those users and set the default status 'non active' for this group.
In this section you can also define what guests can see (e.g. market place, business directory, user search) and what groups they can see, and optionally the profile fields of the users. You can also define in this section if users can register themselves and what will be the groups available.

- Content management, Layout
Although content management items are not directly managed within a configuration they fall into a configuration context. Each configuration can have its own set of pages, themes, layout themes, logos etc. The content management elements are accessible via the menu: Content - Content Management. If an admin has permissions to more than one configuration the content management menu will show first a list of configurations to pick from. Usually it is good practice to create dedicated content administrator groups for specific configurations.

Note1: In more complex systems with multiple groups and permission products it is good practice to chose a clear hierarchical configuration structure. In the higher level configuration you would put all content and settings that are common for all groups. For example language, layout, content pages, possible access channel etc. In case you want specific behavior for a group you can just extend an existing (higher level) configuration and save it with the additional changes you want. Once you add the configuration to the group the new settings or content will be applied for that group. This approach avoids having duplicated information in multiple configurations.
Be aware that one Cyclos can have different 'landing' sites (at different URL` s) with different configurations and rules.

Note2: After changing the configuration settings be sure to save the configuration by clicking the ‘Save’ button at the bottom of the page.

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

Access channels

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, Web services, SMS, Pay at POS, and the Mobile App. 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 can be configured. In the Channel configuration you can specify what identification method is required for users (or third party software) that accesses Cyclos via that Channel. This can be any (unique) profile field such as email, account number, custom fields, and mobile phone number, or a 'token', which can be a card or bar/QR code. The authentication is done by a password. Cyclos has three predefined passwords (login password, transaction password/PIN and OTP) and it is also possible to create a customized password type A customized password type can implement a new password method (using Cyclos scripting), or delegate the authentication to an external service.

Access channel - SMS

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 funcion 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 .

Password types

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 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`, 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 chose from the following 4 `modes`:

- Manual: the password needs to be given when creating a new member.
- Generated: the password is automatically generated upon member creation. The member will receive an email with a temporary password the needs to be changed upon first login.
- OTP (One Time Password): this can be used instead of a fixed transaction password. When a payment is submitted by a user a temporary password code (OTP) will be send by SMS and/or email. The user needs to put the code in to the payment form in order to validate the payment. By default the OTP can be used once, by allowing `reuse` you can set a period (e.g one day) during which the code can be reused for new payments.
- Secondary password: For systems requiring a higher security level a secondary access password can be applied. This password will be requested after a successful login with the primary password. The secondary password can be applied to any channel. It will allow various combinations. For example an admin that logs in could be required to confirm with an OTP that is sent to a validated mobile phone number.
- Script: For more complex password rules you can create your own script

Languages

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. This 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 do manage the translations 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 be 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.

- Dictionaries (keyword indexing)
Cyclos has various keyword search features. For example, you can search for users or advertisements by one or more keywords. The mechanism that is used for keyword searches is `indexing`. This works very similar as as Internet search engines. The Cyclos search engine works with intelligent searches. It will ignore capital/lowercase characters, and it will search for variant forms of a given keyword, for example words with the same grammatical stem, or a plural form if a singular form is provided (and the other way around). An example, a search with the keyword `car` will also return advertisements with the word `cars`, and a search with the keyword `baker` will also return advertisements containing `baking` and `bakery`. As this involves obviously the specific grammar of a language the indexation is different for each language. The indexing in Cyclos is defined at global and network level. The configuration of the indexation is quite straightforward, you just have to select the languages you want enable for indexing/keyword search in the global or default network configuration. In most cases this will be just a single language. If you have a multiple language system and you want users within different languages scope to be able to find each other (or each other advertisements) you will have to enable all the dictionaries in the default network configuration. The dictionary select box has also an option called `Default`. This option will use just ignore the case (capital and lowercase letters) and apply a wild-card (*) search for each word. Be aware that this offers more limited searches. If the dictionary setting is changed all indexing entities (e.g. user names, advertisements) are re-indexed, so the setting can be changed afterwards without the risk of inconsistent keyword search results.

Vouchers

Menu: System - Account configuration - Voucher configurations Menu: Banking - Vouchers

Vouchers can be used for specific payment purposes such as gift vouchers or discount coupons. The owner of a voucher can spend it at an intake point, for example a shop or a restaurant. For each voucher type different rules can be applied. You can for example restrict where vouchers of a specific type can be redeemed (at a specific shop, or a group of business, or all business in the Cyclos system), at what specific week days they can be used, the period in which it can be used, and the maximum amount of each voucher. It is also possible to specify a customized logo and a description for each voucher type. The voucher has a unique identification number or `token` that can consist of numbers and letters. The token can be represented as text or an image such as a QR code. The shop will type in the number or scan the QR code and after confirmation the shop will receive directly the units on his account. Depending on account type the amount was either reserved (positive only system account) or debited directly in case it comes from a negative only system account.

Vouchers can be generated in Cyclos by an admin and printed directly (single voucher or bulk print), or exported to a CSV file and send to a printing company or card maker. There is also an option that allows users to buy vouchers directly in Cyclos. A voucher page shows all voucher offers that are published. For example a restaurant can offer a certain amount of vouchers to be bought during a specific period. This type of voucher offers will usually limit the maximum amount for each user. A user that buys a voucher in Cyclos can print it out and use it at the shop or business. From the mobile app version 1.4 on users that buy vouchers can also view them in their `voucher wallet` in the mobile app. The voucher will show the details and a QR code, that can be scanned/redeemed by the shop in the same way as a paper voucher.

- Configuration
In order to enable vouchers in a Cyclos system you need to start with a voucher configuration (System - Account configuration - Voucher configurations). In this page you define the basic information such as currency, transaction types and voucher token mask (if a more specific voucher format is needed a voucher extension point is available). These tasks are usually done by the system administrator. Once a voucher configuration exists you can give administrators the permissions to created voucher types based on one or more voucher configurations (Admin group - Permissions - Accounts - Vouchers). When this permission is defined admins will see a section called Vouchers in the Banking menu. From there they can create and manage voucher types and vouchers. These are the operational tasks of the voucher administration. For the users the Vouchers will also show up in the Banking menu. Be aware that this menu is only visible when the users have the permission to buy vouchers. Vouchers that are generated & printed by an administrator do only involve the account of the redeemer (shop), and not the user that pays with a voucher.

- Notifications
When a voucher is going to expire in 3 days the user will be notified (only vouchers that are bought by the user via the buy voucher option in Cyclos). Once a voucher is expired the user will also receive a notification. Both notifications can also be enabled for the administrator, this can be done in: Personal - Settings - Notifications.

Custom fields

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 and record, Contact and Business contact (in user profile).

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. 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 to link 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.

Advertisements categories

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 categories 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.

Advertisements fields

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.

Advertisements authorizations

Menu: System - Groups - Select admn group - User data section - Pending ads Menu: System - Products - Select Member product - Advertisment 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 en new advertisement he will be informed that it needs to be reviewed. When an broker or admin authorized the advertisement will be published and the user (publisher) will receive a notification. When the users 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 send on each status change.

Web shop

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 managements comes with stock management and automatic product numbering. 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 tool bar.
Detailed information about the advertisements and web shop can be found at the online specification page.

Profile fields

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.

Custom image categories

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.

Records

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 be able to search for specific values (the custom fields belonging to a record). 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 consist 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. Usually records have 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 it`s 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 give 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 creating date, and 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 a user profile), or open them directly in edit mode.
It is also possible to create sections with titels for a record. This will be usefull for the visiblity for records that contain many fields.

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.

Records can be very usefull in the combination with the scripting module (see Online documentation - 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 new values/entities. 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.

Agreements

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

A registration Agreement is a text that can be shown at the registration page. Users who want to register MUST select a checkbox stating that they agree with this agreement in order to be able to submit. Agreements are created by administrators and assigned to products. Once an agreement has been accepted by a user (upon registration) an agreement cannot be changed anymore by administrators. At the agreement page the agreement text will appear with a new (generated) version number, this version can be changed, until it is accepted by the first user, after which a new version number will appear, and so on. The older 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. Version changes will not force the user to accept the agreement 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 that are assigned new/other products with different agreements.

Message categories

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 of the users, and in an administrator group permissions you can define what messages (categories) an administrator can manage.

User identification methods

Menu: System - System configuration - User identification methods

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 are 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 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 op 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 can be configured for the third party access. The third party software will communicate with Cyclos via the Cyclos API. Third party software can connect to Cyclos using a java client, a php client or a “REST level 0” client, this is described in more detail in our online documentation: www.cyclos.org/documentation 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/

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 identifications methods involves privacy and security. It can be handy to allow user 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 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.

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 en email with a link to explore Cyclos.
The invite text is defined by the administration (MESSAGING.MESSAGES.inviteMessage.body.admin)

Cyclos scripting

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 adminstrators can be given permissions to bound the scripts to elements such as extension points (eg. payments, user profile), custom validations (fields), custom calculations (account fees, transaction fees), custom operations and scheduled tasks.
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 exists (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 how to run the code locally and how to debug it.

Detailed information about Cyclos scripting can be found in the Cyclos documentation (section 3, scripting).

Custom operations

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 Cycos 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 advertistement, 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 be 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 ore 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).

Imports

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

The import functionality can import the following (user) information:
- Users together with all profile fields, addresses, phones and profile images
- Advertisements
- Records
- References
- Transfers
- Tokens (e.g. cards)
This information can be imported by clicking on the import button and following the import steps. 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 the Banking menu.

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

Cyclos license

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 in global mode.

Tickets

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

The ticket system provides a secure method for payments done via third party channels, for example a payment at third party webshop. The ticketing systems 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.

- Processing Cyclos payments by third parties.
A webshop or other third party that wants to accepts Cyclos payments can generate a payment link or QR code for payment confirmation. Detailed information can be found at this wiki page.
- QR code payment request
In the Cyclos mobile app it is possible to generate a QR code payment request. The payment amount, receiver, and an optional description are included in the QR code. The payer will have to open the Cyclos mobile app and scan the QR code generated by the receiver. The payment data will be show and after confirmation by the payer the payment will be done. Both payer and receiver will receive a direct (push) confirmation.
It is also possible to send a payment request from the phone or tablet to other channels such as what's app or email. This way the payer does not need to be physically present at the shop.

Note:
For both ticket payment methods that use payments there is a Cyclos page where the payment receiver can see a complete live and historic overview of all tickets and status related to tickets.

Content management


Content management deals with layout and content. For the two first items (Documents and Custom images) to be used a 'category' needs to be created first (in System - System configuration). After the categories are created you can assign them to admin groups (view or manage permissions in System - System configuration). In order to customize a language (Application translation) an admin has to extend a built-in language first, and will need to set the permisson in an admin group to manage the translation (as explained further on).

All other Content management items (menus, pages, logos, themes, banners, SMS texts) are part of a configuration. This means that it is not necesary to create a category and set permissions. When an admin has permissions to view or manage a configuration he will get automatically the permissions to access the content items. When an admin selects a content item in the Content management menu (e.g. Themes) and the admin has permissions to manage more than one configuration, a list with available configurations will be showed first. Clicking on an configuration in the list will open the content item for that specific configuration.

Documents

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 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 formated. 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 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.

Custom images

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)

Application translation

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 consist 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 translations a list will be show first.

Data translation

Menu: Content - Content management - Data translation As explained in the section above, the Cyclos `hard-coded` translations keys like menus items, form labels, notifications and other texts are defined in the application translation. Cyclos has many 'dynamic' (non hard-coded) 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)

Static content

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, the header, footer 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.
Detailed information about the static content can be found at the online specification page.

Menu & pages

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 chose 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 showed.
Detailed information about the static content can be found at the online specification page.

Banners

Menu: Content - Content management - Banners

Banners can be added at the left and/or right of the main Cyclos windows. When putting more than the maximum amount 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.

Mobile app layout

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. The pages will be shown after clicking on the shortcut icon in the mobile app home page.
The page, title and icon can be edited in: Content > Content management > Mobile pages.
Also the mobile theme can 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.
Finally the login header, login footer, mobile help and mobile POS help can be customized through: Content > Content management > Static content.

SMS texts

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.
The pages will be shown after selecting a shortcut icon in the mobile app home page (for logged users). When adding a new page a shortcut icon can be selected.
Detailed information about the mobile app pages can be found at the online specification page.

Logos

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.

Themes

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 two types of themes; Web theme and Mobile (app) theme. 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 to create a new theme in a few minutes. The second level is done by changing common theme elements by predefined LESS variables. Normally variables are used to group layout items that logically share the same value (e.g. all window borders). The third customization allows to customize the entire CSS file. When creating a new theme you have to 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.

Reports & Alerts

System reports

Menu: Reports & Alerts - Reports - System reports

At the system reports page you can retrieve overview of 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:

- Gross product: the total sum of earned (incoming) units on all accounts, with respect to the group- and payment filters specified, and within the period specified.
- Number of transactions: the total number of transactions where at least one of the participating members belongs to the specified groups in the group filter, and where the transaction belongs to the specified transfer type in the payment filter, and which took place in the specified period.
- Percentage of members not trading: The percentage of members who was not involved in any incoming or outgoing transaction (with respect to group- and payment filters, and inside the specified period).

System alerts

Menu: Reports & Alerts - 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.
Note: A notification can be generated on system alerts, this can be configured in Menu: Personal - Preferences - Notifications.

User alerts

Menu: Reports & Alerts - Alerts & Logs - User alerts

Typical user alerts are: failed password attempts, new pending user, expired loan etc.
Note: A notification can be generated on user alerts, this can be configured in Menu: Personal - Preferences - Notifications.

Error logs

Menu: Reports & Alerts - Error logs

Errors that occur in Cyclos will show up in this list. An error is typically a software bug and needs to be solved by the software development team.

Licensed to: Social Trade Organisation