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
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 settingsMenu: 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.
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 userQuick 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 contactsMenu: 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 contactsMenu: 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 usersMenu: 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 userMenu: 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 userView 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.
Make a batch payment to usersView user profile - Banking - Payment system-to-user Menu: Banking - System payment - To user Menu: Users - Management - User profile
With batch payments members can perform payments to multiple users in one batch. This can be done by importing a file with the destination users and the amounts to be paid (and optionally description and other fields). The batch payment feature has a preview function that will show detailed data about the batch to be performed (how many users, possible failed users, amount per user, total amount). There is also a history that will show this data per batch.
Change credit limit of userView 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
Note: In the account limits overview page you can search on individual credit limits.
Change group of userView 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.
When a user has the removed status he/she won't be visible in any way to other users, and no operation related to this user is possible. It is as if the user was removed from the system, but the user data is kept and is accessible for admins (with the permissions). The reason that the user data is kept is because this is often required for financial institutions. However, when needed it is also possible to 'purge' users, this means that all private data is completely erased. A system admin can define which private data (e.g. addresses, custom fields, built-in fields, record types) is erased on purging.
Manage user passwordsView 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 userView 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 userView 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 userView 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
More information about cards (tokens) can be viewed in this help section.
Assign broker to userView 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 documentView 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 userView 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 userView 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 userView 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 usersView 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 overviewMenu: 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 overviewMenu: 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 limitsMenu: System - Products - Select Member product - Accounts - Balance limits Menu: Banking - General overviews - Account limits Manage user (from profile): Banking - Balance limits
Accounts balances can be limited, meaning that it is possible to define
a maximum and minimum account balance. When a negative balance limit
(overdraft) is set, it means that the user cannot make any payment if
the balance will go over the limit. The user will have to top-up his
account or receive a payment in order to be able to make payments
again. When a positive balance is set the user cannot receive any more
payments when the limit is reached. The account balance limits can be
defined at product level and individual level. There is a general
overview page of account limits per user.
Various search filters are available. It is possible to enter an account limit from the search results. From this page an admin (with permissions) can change the account limits (this can also be done from the user profile). Account limit changes are always stored to the history log (tab) with the user that performed the change, the values of the change and a time stamp.
Manage payment limitsMenu: System - Products - Select Member product - Accounts - Payment limits Menu: Banking - General overviews - Payment limits Manage user (from profile): Banking - Payment limits
It is possible to define minimum and maximum amounts limits for
payments. As with account limits the payment limits can be defined at
three levels: in the transfer type, in the product, and at individual
level (at the management section in the user profile). In the transfer
type it is possible to define the max amount per payment type per
day/week/month/year, and the max number of payments, also per
day/week/month/year. The payment limits in the transfer type are
leading (they cannot be overwritten by product or individual settings).
An admin or broker with the permissions can also define max amounts at individual level. The individual max amounts will overwrite the default settings in the product.
From the user profile (management section) there is a page that will show all active payment limits for the user, and an option to change them. There is a general overview (search) page for all payment limits.
Bulk actionsMenu: 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 userView 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.
CurrenciesMenu: 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.
AccountsMenu: 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
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 feesMenu: 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 typesMenu: 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 feesMenu: 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 fieldsMenu: 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 statusAccount 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 filtersMenu: 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 authorizationsMenu: 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.
It is possible to define an amount range in an authorization level. If an amount range is configured the authorization level will only be applied when the transaction amount is within the amount range. The range can be configured with an ‘upper’ and ‘lower’ limit, but it is also possible to select just one option. For example, if only a lower limit of 100 is defined (and no upper limit) any payment above 100 will apply.
Detailed information about authorizations and roles can be found in the online specification page.
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 paymentsMenu: 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 paymentsMenu: 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 requestsMenu: 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) userMenu: 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.
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
Note: Be aware that the easy invoice is just a link to a payment, it does not generate a payment request or a ticket.
NetworksMenu: 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 wizardMenu: 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.
WizardsMenu: System - Tools - Wizards
A wizard in Cyclos is a ‘flow’ of steps where each step is a page that
can contain form fields or built-in functions. It works much like a
custom operation, but where a custom operation consists of a single
page, a wizard is a flow of pages with a first step (page) and a last
last step (the finish). On the submission and loading of each page/step
script code can be run.
Within the flow there can be different ‘branches’ according to the options chosen by the customer. A wizard can be shown in a menu (as guest or logged user) - it can accessed via an easy readable URL, and it can be used for the registration of new users. The wizard has various available built-in features. For example, integration with external identity providers such as Facebook or Google, email validation, captcha etc. It is possible to integrate a step with a third party service, for example for KYC (know your customer) purposes.
GroupsMenu: 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.
ProductsMenu: 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'.
There are three types of products: member product, broker product and admin product. The member is the main product for end-users (non admins). The broker product contains mostly broker features. Please note that if you want a broker to have typical member functions (e.g. having an account), you must create a broker product as well as a member product (containing the account) and assign it to a broker group. Administration permissions are defined directly in an administration group (under the permissions tab), but for more complex configurations with many different admin groups it is possible to define the common permissions in a 'shared' admin product. For systems that have few admin groups, or admin groups with little common permissions, it is not necessary to create administration products.
- 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.
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).
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.
OperatorsView 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).
ConfigurationsMenu: 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.
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.
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 channelsMenu: 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, Mobile App, Ticket
and Easy invoice. It is also possible to add new channels, for example
for communication with third party software. When a user, or third
party software, accesses Cyclos via a Channel an identifier and
authentication needs to be provided. This is typically a userID and
password, but different types of identifiers and authentication methods
can be configured.
In the Channel you can specify what identification method is required for users (or third party software) that accesses Cyclos via that specific Channel. This can be any (unique) profile field such as email, custom field, and mobile phone number, the account number (if configured) or a 'token', which can be a card or bar/QR code. There are various authentication options: login password, transaction password/PIN, OTP and Trusted Device. A Trusted Device is a device that runs the Cyclos mobile app and has been confirmed by OTP (via SMS or email). It is also possible to create a customized password type using Cyclos scripting, and you can delegate the authentication to an external service.
Users can also register and authenticate with external identity providers such as Google and Facebook.
Access channel - SMSThe 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 typesMenu: 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
LanguagesMenu: 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
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.
VouchersMenu: 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.
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.
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 fieldsMenu: 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 categoriesMenu: 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 fieldsMenu: 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 authorizationsMenu: 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 shopMenu: 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 fieldsMenu: 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 categoriesMenu: 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.
RecordsMenu: 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.
AgreementsMenu: System - User configuration - Agreements Menu: System - User configuration - Member product - Agreements View user profile - Accepted agreements
An agreement is a text that can be shown at the registration page and
the login page, with a select box that the user can check before
submitting. There are required and optional agreements. Upon
registration, users will have to select the required agreements, and
can optionally select the non obligatory agreements. All agreements
have a clickable link that opens the agreement text in the pop-up
Agreements are created by administrators and assigned to products. If an agreement text is changed by an administrator a new version of the agreement is automatically created. 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 users that are assigned new/other products with different agreements.
Older agreement versions can still be seen in read only mode by the administration. There is a full history of accepted agreements (per user) and the version that was accepted. For end users (non admins) an overview page is available from the personal menu in Cyclos. Users can see the agreements with historical data (agreement acceptance date) and can select or unselect the optional agreements.
An agreement extension point is available. This makes it very easy to add business rules upon agreement status changes. For example, when a specific optional agreement is accepted an individual product could be assigned automatically to a user.
Privacy controlMenu: System - User configuration - Privacy control Manage user: - Privacy settings
Privacy control in Cyclos is a mechanism that allows users to specify
what personal data can be accessed by which departments. The privacy
control feature is added for compliance with regulations such as GDPR.
An administrator can define ‘privacy admin groups’, for example a group called ‘accounting’ or a ‘commercial’ group. The users can select which administration group is allowed access to their personal data. There can be ‘required’ privacy groups that the user cannot unselect.
Message categoriesMenu: 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 methodsMenu: 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 usersMenu: 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
The invite text is defined by the administration (MESSAGING.MESSAGES.inviteMessage.body.admin)
Identity providersMenu: System - System configuration - Identity providers
Cyclos supports the OpenID Connect standard, which allows users logging
into Cyclos with credentials (e.g. userID/password) of other platforms
such as Google or Facebook. OpenID connect can be enabled for the
registration of new users in Cyclos. Before the registration process
the user can select the external identity provider and authenticate.
User data from the third party platform (e.g. email and address) can be copied automatically to the Cyclos registration form and saved to the user profile. This can be very convenient for the quick sign-up of new users.
Cyclos can also act as a OpenID Connect server. With this service third party software can allow users to login into their system with Cyclos credentials. More information can be found at these wiki pages:
Wiki4 - External identity providers
Wiki4 - OpenID Connect-OAuth2
Cyclos scriptingMenu: 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 operationsMenu: 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).
ImportsMenu: 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
- 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 licenseMenu: 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.
TicketsMenu: 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
- 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.
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.
Front-endMenu: System - Configuration > Section: New front-end Menu: Content - Static content / Menus and Pages / Banners / Themes
Cyclos has two built-in front-ends, the classic front-end based on GWT
(Google Web Tools) and a more customizable and modern front-end based
on the angular and bootstrap frameworks. The new front-end is
responsive meaning it displays (resizes) well with different screen
sizes and resolutions (from larger monitors to smartphones).
The new front-end is intended for end-users and some administration functions are not available. The GWT based front-end has all available Cyclos features. Which front-end will be used can be defined in a configuration (that can be bound to a group).
If the new front-end is defined for a configuration that is bound to an administrator group the users (admins) of these groups can always switch between the new and classic front-end.
The customization of both front-ends can be done from within Cyclos. The new front-end is based on an open source project and uses the RESTful API and can be completely customized. Detailed information about the new front-end can be found at this wiki page.
The history log is basically a page with a complete history of all the
changes that are made to a Cyclos entity. History logging is available
for the entities: profile, record, advertisement, configuration,
channel, group, product, currency, account, transactions, fees,
authorization level, password type, identification method, voucher
type, voucher configuration, agreements and scripts.
The history log is available as a tab or a link in the entity details page. For example, clicking on the link 'Profile history’ in a user profile (as admin or broker) will open a page that lists all profile changes that were made since the user was created (e.g. change of email, address, etc.). The history log page contains for each change the following information: the old and the new value, the username and IP address of the user that performed the change, the timestamp of the change, and the channel through which the change was made.
All history log pages have search filters to facilitate the search in case there are many results. Of course, besides the history logging, Cyclos still logs all operations and changes to the Cyclos log files (or to a dedicated logging database depending on the configuration).
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.
DocumentsMenu: 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 imagesMenu: 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 translationMenu: 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 shown first.
Data translationMenu: 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 contentMenu: 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.
There are many notifications that Cyclos can send via email. For example, a registration confirmation email, an email when receiving a payment, or an advertisement match. With the use of email templates it is not necessary to change the notifications, but a single email template can be used to define a general layout for all notifications. The template has a rich text editor and you can include variables. The template feature has a preview so that you can directly see how the message will look.
Detailed information about the static content can be found at the online specification page.
Menu & pagesMenu: 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.
BannersMenu: 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
Detailed information about the banners can be found at the online specification page.
Mobile app layoutMenu: 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 textsMenu: 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.
LogosMenu: 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
Detailed information about the logos can be found at the online specification page.
ThemesMenu: 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 reportsMenu: 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 alertsMenu: 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
Note: A notification can be generated on system alerts, this can be configured in Menu: Personal - Preferences - Notifications.
User alertsMenu: 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 logsMenu: 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.