|
|
| (78 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | {{template:admincomingsoon}}
| + | [[File:helpheader_small.png|right]] |
| | | | |
| − | This document is a walkthrough of the Administration menu, which contains almost all of the settings used to administer your whole Charitylog system. This is a long document. Rather than trying to read through the whole document in one go, you might like to consider using the links out of Charitylog to find the help content you need. Above the navigation menu on each Charitylog page is a button like this: [[File:wikibutton_1.png|border]]. Clicking on this button will take you to help content relating to that page.
| + | __TOC__ |
| | | | |
| − | If you haven't already done so, it is strongly recommended that administrators read the [[Introduction to Charitylog for Administrators]] and the [[Quick Start Guide for Administrators]] before this one.
| + | The system is designed to be customisable for each organisation that uses it. Before you get going you will be provided a pre-implementation spreadsheet to complete, from this a system is created. This guide will talk you through the various steps that are needed to get your system set-up. |
| | | | |
| − | ==Accessing the Administration section== | + | =Pre-Implementation Spreadsheet (not used for [[Modules| Members, local and single project system]]).= |
| | + | The pre-implementation spreadsheet is used to save time on the first day of setting up your system. It contains pages to configure some of the basic dropdowns that you may use. If the dropdowns are not required then the options can be left blank. The lists that are created can be added to at a later date if required. Any thing that is not on the forms will be discussed with you Implementation Consultant on your setup days. Below is an explanation of each page of the spreadsheet. |
| | | | |
| − | To set up your system you will need access to the Administration menu. It is at the bottom of the main menu which appears in almost every Charitylog screen. If you can't see it, it is because you do not belong to a user group which is granted access. You need to contact one of your system administrators and request to be moved to one of the relevant [[System_Setup_Guide#About_Users_and_User_Groups|User Groups]].
| + | '''Introduction''' |
| | + | The Introduction sheet give you details on how to complete the forms. |
| | | | |
| − | ==Our Details==
| + | '''Organisation Details''' |
| | + | Enter the details of your organisation. The specified organisation name will be used to name your new system as well as will be used to generate log in details. |
| | | | |
| − | This section is for details of your organisation.
| + | '''Ethnic Groups''' |
| | + | Ethnic groups are generally use for reporting outputs. Populate a list based on what your organisation requires across all services. |
| | | | |
| − | Text entered in the box will be shown to all users when they log in (under the user-specific username/password entry page).
| + | '''Age Groups''' |
| | + | Age groups or bands are used for calculating a person Date of Birth and as a reporting output. Age Ranges must not have any gaps or cross overs and start at 0, finishing at 999. |
| | | | |
| − | ===Contact email address===
| + | '''Religions''' |
| | + | If your organisations requires to support or report on religious groups then enter the name of each group you need. |
| | | | |
| − | This is the reply-to address that will appear on system generated emails. It's worth checking this before your system goes live; sometimes in pre-implementation it is set to the email address of the main contact in your organisation, which is often the chief executive. Leaving it set like this may lead to users sending out emails which appear to have come from your chief executive.
| + | '''Sexual Orientation''' |
| | + | In addition to the gender field on the system there is the option to record a persons sexual orientation. |
| | | | |
| − | It's important to have something filled in this box, as without it, system generated emails will be sent as if they have no sender, which often means they get diverted to spam folders. Note that the system won't check this email address for validity, so it's up to you to format it properly. Alternatively, you might like to use a "donotreply@" address.
| + | '''Districts/Wards''' |
| | + | On the records is the option to place people/organisation into reporting areas. This list is to populate those areas. Examples being boroughs, counties, areas and districts. |
| | | | |
| − | ==Referral Audit==
| + | '''Disabilities''' |
| | + | This is used for specifying a persons disability/ailment and can be used in reporting. An individual can have multiple. |
| | | | |
| − | The Referral Audit feature is intended for service managers to independently audit the work your organisation has done, usually by telephoning the client and checking that they are happy. Clicking the "Referral Audit" link will show you a display of the referrals on your system. You can narrow these results by date range, the user that entered the referral, Project, whether they have been checked already, and whether the referral(s) in question are complete.
| + | '''Marital Status''' |
| | + | If required populate with the marital statuses that you use. |
| | | | |
| | + | '''Relationships''' |
| | + | The system can link records together using relationships. Personal relationships can include relationships with keyworkers like Social Workers etc. When adding a relationship you need to think about the opposite match, example Husband & Wife, Support Worker & Supported Person. |
| | | | |
| − | [[File:SS_1.png|790px|border]]
| + | '''Contact Methods''' |
| | + | This is for the physical contact methods that would be used, telephone, email, one to one etc. This is also used for preferred method of contact and transportation options. |
| | | | |
| | + | '''Staff and Users''' |
| | + | It is very important that you included at least one system administrator, this person will also need to be at the Implementation Meetings for the setup of the system. You need to specify: |
| | + | * '''Volunteer, Staff or Trustee''' - This will create a record to attach to the user. |
| | + | * '''Surname and Forenames''' - This is used to populate a user record if require. The system will be setup to use the person first name and initial from the surname in lowercase, Jane Smith will be given a username of janes. If you have two people with the same names or first name and surname initial the same, the system will cater for this. |
| | + | * '''Is a system user''' - Yes will create a record for the person as well as a user account, maybe and no will only create a person with no login access. |
| | + | * '''User Group Names''' - The system is setup with 4 groups to start which can be changed at a later date. Do not rename the dropdown options or use something not in the drop down. Make sure you have at least one administrator. |
| | + | * '''Email Address''' - Used for password recovery. |
| | | | |
| − | Clicking a "Check" button will show you -
| + | '''Accommodation Types''' |
| | + | This specifies the types of accommodations a person may live in; council house, social housing, private owned, private rented, HM Prison, care home, hostel, no fixed abode etc. |
| | | | |
| − | * The client's contact details
| + | '''Living arrangements''' |
| − | * The details of that referral
| + | This is for how a person live at the accommodation,; lives alone, with partner, with parents, multiple occupancy cell. |
| − | * Simple diary outcomes
| |
| − | * A "Check Completed?" box.
| |
| | | | |
| | + | '''Referral Sources''' |
| | + | Referral sources are 'How did you here about us' include things like Advert, website, web search etc. |
| | | | |
| − | [[File:SS_2.png|790px|border]]
| + | '''Service User Group''' |
| | + | Service Users groups are a way of categorising your service users, used for Young Persons, Adults and Older person. Please note that a service user can only go in one category. |
| | | | |
| | + | '''Status''' |
| | + | Statuses are commonly used on a carers system for things like, young carer, young adult care, adult carer, ex-carer and cared for. Can also be used for High need, medium need and low need. |
| | | | |
| − | You may like to consider using Simple Diary Outcomes specifically for audit checking, since Project-specific outcomes are almost always better when structured as Ladder Outcomes.
| + | '''Termination Reasons''' |
| | + | Termination reason are used when removing a service user from a project, specifying why a service is no longer required. |
| | | | |
| − | Once checked, you can fill in the required outcome and/or add notes, set the "Check Completed?" field to "Yes", and click the "Save and Close" button.
| + | '''Referral Outcomes''' |
| − | ==Standard Document Setup==
| + | These simple outcomes are case closure outcome like case closed successful claim. |
| | | | |
| − | ===Publication Setup===
| + | '''Organisations we signpost to''' |
| | + | Enter the names of organisations that you signpost to (and specify if you receive referrals from. This will create an organisation record for each. If you are having a data migration you could add the organisations to the migration with full contact details and not fill in this section. |
| | | | |
| − | Setup of Publication Categories is dealt with in the [[Office_Functionality_(Administrator_guide)#Publication_setup|Administrator Guide to Office Functionality]].
| + | '''Benefits''' |
| | + | You can add benefits and amounts if you assist your service uses in this area. |
| | | | |
| − | ===Standard Letter Templates===
| + | '''Gender''' |
| | + | Enter the genders that you work with, think about adding categories for gender re-assignment. |
| | | | |
| − | Standard letters are dealt with in the [[Office_Functionality_(Administrator_guide)#Standard_Letter_Templates|Administrator guide to Office Functionality]].
| + | '''Contact Types''' |
| | + | Contact types are used to distinguish direct and indirect done for a service user. |
| | | | |
| − | ===Uploaded Doc. Categories===
| + | '''Main Language''' |
| | + | Used to specify the main spoken language of your service users. |
| | | | |
| − | This menu item shows the categories that are set up on your system to categorise uploaded documents, which can be uploaded and stored with the details of any organisation/person on your system. Users can use the categories to categorise a document when they upload it. An example set of categories is shown. You can use these categories in any way you like - whatever suits your organisation.
| + | =Implementation meetings and training (additional service for [[Modules| Members, local and single project system]]).= |
| | + | Once the system has been created you will be contacted by your Implementation Consultant to discuss moving forward. The implementation days are used to look at your organisation in details and set the system up accordingly. You will be shown every step that is required and run through the options available. This is an important step to getting set up and running and the full process will be planned by your designated consultant. |
| | | | |
| | + | Full details of this will be sent via email. |
| | | | |
| − | [[File:SS_11.png|border]]
| + | =Set up and Administration Settings= |
| | + | Before the system can be used there are some steps that need to be taken. In this section you will find guidance to what needs to be set up in relation to the core settings of the system. |
| | | | |
| − | ==Drop-Down Lists== | + | ===Group Access (Not available on Local or Members systems)=== |
| − | {{template:admincomingsoon}}
| + | It is worth familiarising yourself with the group access security and checking that the system administrators group has full access to the system. Before starting ensure that the System Administrator group has full access to all areas of the system. For further details see [[Group Access]]. |
| | | | |
| − | Throughout your Charitylog system there are drop-down lists. These are preset lists which can be edited from the '''Drop-Down Lists''' menu. Drop-down lists are simple, but fundamental to Charitylog. In particular, if you have certain reporting requirements, you need to make sure that the drop-down lists are set up so that users can log data which usefully matches these requirements. For example, if your funder has a certain list of ethnic origins that they want you to categorise your contacts by, you will need to make sure that the drop-down list of ethnic origins matches their list.
| + | ===System Details=== |
| | + | System details allow you to enter your organisation details with a section to add a message for users as they log in. |
| | | | |
| − | ====Note for system administrators and chief executives====
| + | [[Organisation Details]] |
| | | | |
| − | Because all of the drop-down lists are customisable, getting these drop-down lists correctly set up is a very important way to start your Charitylog implementation. They will be set up for you depending on what you enter on your pre-implementation spreadsheets. There are default values for some of them (for example, the list of age ranges), but remember that these can be changed. However, it is difficult to change drop-down lists when users have already started using them, as you risk compromising the integrity of your data - so give the drop-down lists some careful thought before you start implementation, if possible.
| + | ===Operational Rules (Not available on Local and Members systems)=== |
| | + | This is an important section that is not to be overlooked as it contains the overall security settings for accessing the system. Some of the other items may not seem relevant in the early days and you may find that you will revisit this area at a later stage. |
| | | | |
| − | Some drop-down lists (like Age Ranges) are universally used in the same way. Some are slightly less specific, and can be used for anything that your organisation needs. Your Implementation Consultant will be able to help you set these up and advise you on which is most appropriate to use.
| + | [[Operational Rules]] |
| | | | |
| − | ====Accomodation Types==== | + | ===3rd Party Software=== |
| | + | Review the 3rd party software if you wish to use any of the optional systems. If you wish to use the email options within the system it is highly recommended that you use your organisations own email server. You may experience issues if you use our servers depending on the setup of your domain. If you have Spoofing Protection enabled most recipients will reject the email and send a message failure notification back to the system. If you do not have Spoofing Protection enabled most recipients will accept the email with a high chance of marking it as Junk Mail/Spam. When you use our system the email is sent on your behalf, using your specified email address, this method is now known as spoofing. |
| | | | |
| − | Accommodation Types are found on the Personal Details tab of person-related records - clients, carers, volunteers and so on.
| + | ===Records and settings (This feature is restricted on Local and Members systems)=== |
| | + | Think about which record types you require, from Clients through to the organisations that you work with. With each of the record types you also need to think about which fields to include on these records. To customise the records see [[Customise Orgs & People]]. |
| | | | |
| − | [[File:SS_12.png|border]]
| + | ===Field setup=== |
| | + | Once you have chosen which fields are going to be used you can the setup these fields. |
| | | | |
| − | ====Age Ranges====
| + | [[Admin#Orgs_and_People_A-J| Dropdowns for records_A-J]] |
| | | | |
| − | The Age Ranges drop-down list is in fact a set of age bands. When a user enters a date of birth on a client's record (or another person type), the system will automatically set their age band accordingly. You may have sets of standard age bands which you have to use, set by a national body or a funder. Alternatively you may be at liberty to choose your own.
| + | [[Admin#Orgs_and_People_K-Z| Dropdowns for records K-Z]] |
| | | | |
| − | [[File:SS_13.png|border]]
| + | ===General Settings (Some features not Available on Local and Members systems)=== |
| | + | Configure the following general settings: |
| | | | |
| − | Clicking on the name of an age band will let you edit it, set the upper and lower limits, and so on. Care should be taken with the display order to make sure that the age bands display in age order, unless there is a very good reason not to - users will often find it confusing if age bands are displayed in any other way.
| + | * [[Field Sets]] - A field Set is used to determine which fields are used by the various services in your organisation, these are made available to users via the projects. |
| | + | * [[GDPR Settings]] - General GDPR settings. |
| | + | * [[Consent Rule Text Entry]] - Setup for custom consent rules. |
| | + | * [[Bank Holiday Dates]] - Some reports can report on working days and require the dates to be populated. |
| | + | * [[Branch Groupings (Views)]] - '''Requires Branch Module''' - If on a branch system you can setup groups of branches. |
| | + | * [[Branches/Offices]] - '''Requires Branch Module''' - The main setup for the branches on the system. |
| | + | * [[Information Links Headings]] - Used for adding organisations to a directory of services. |
| | + | * [[Publications]] - Use if you need to report on what publications you give away. |
| | + | * [[Publication Categories]] - The types of publications that you have. |
| | + | * [[Publication Languages]] - The languages of your publications. |
| | + | * [[Supporting People Settings]] - Setting for the [[modules| Supporting People Module]] |
| | + | * [[Uploaded Document Categories|Uploaded Doc. Categories]] - Categories for the types of files you upload to records. |
| | | | |
| − | [[File:SS_14.png|border]]
| + | ===Configuring your Services (Some features not Available on Local and Members systems)=== |
| | + | Services are setup as projects in the system. One service may require one or more projects based around reporting requirements. You may also wish to consider have enquiry projects separate to the service provided. When it comes to reporting the enquiries will be reported separately to the projects that offer a set service. |
| | + | Example |
| | + | You offer home support to people, a person calls to enquire about what options are available. If you record this in the Home Support project it would be reported that the person became part of the project and was supported in some way. If this was recorded in a General Enquiries project then it would not affect the statistics of the Home Support Service. |
| | | | |
| − | ====Benefits====
| + | Set up the following: |
| | | | |
| − | If your organisation does any work around helping people to apply for benefits, and/or you need to store information on what benefits your clients are currently receiving, you will need to set up these benefits in this drop-down list. When recording information about a client, users can pick the relevant benefit and the figures will automatically be carried in according to this list. Here, the list has been set up with the different rates for the two DLA components (as at May 2013).
| + | * [[Project Funding Streams]] - This allows you to specify which funder would fund each contact made. |
| − | | + | * [[Classification Code Setup| Classification Codes]] - Reporting codes for contacts/work done. |
| − | [[File:SS_15.png|border]]
| + | * [[Project Set Up]] - The projects for your services. |
| − | | + | * [[Project Subcategories]] - Subcategories for the projects |
| − | ====Categories of Need====
| + | * [[Referral Templates]] - Workflows for the projects. |
| − | | + | * [[Termination Reasons]] - Why people leave the service. |
| − | Categories of need are one of the lists without a prescribed function, and you can use them to categorise clients if needed (example shown).
| + | * [[Signpost/External Referral Types]] - Sub categories for signposts and external referrals. |
| − | | + | * [[Referral Reasons]] - Why people are referred to you. |
| − | [[File:SS_16.png|border]] | + | * [[Referral Sources]] - How your clients/service users heard of you. |
| − | | + | * [[Contact Types]] - Direct and indirect categories for contacts. |
| − | They do have one specific use, which is for [[Supporting People]]. If your organisation does not take part in Supporting People, you can use them in any way you wish.
| + | * [[Contact Methods]] - How you communicate with people. |
| − | | |
| − | ====Client Personal Options====
| |
| − | | |
| − | The Client Personal Options menu is likely to be expanded or restructured in a future release. At present it only has one option in it - Payment Methods. This is mirrored from [[Accounts_Module_(Administrator_guide)#Payment_Methods|Payment Methods]] in the Accounts module. The "Client Personal Options" menu can be ignored unless you are using the Accounts module, and even then you should not need to actually use it.
| |
| − | | |
| − | ====Communication Methods====
| |
| − | | |
| − | The list of Communication Methods on your system are used whenever a contact is recorded with a client (or any other Organisation or Person type). Users will pick from this list when recording the contact, to say what form that contact took. If you want to report on the different numbers of contacts your organisations has carried out (telephone calls vs office drop-ins, etc) then this list needs to be set up from the start to reflect the contacts you want to track. An example set of communication methods is shown here. Note that these are subject to [[Display Order]], and because users will use this drop-down list all the time, it is important to set the order correctly.
| |
| − | | |
| − | [[File:SS_17.png|border]]
| |
| − | | |
| − | ====Consent Rule Text Entry====
| |
| − | | |
| − | This menu item will let you enter options which will appear on the client's [[Organisations_And_People#Extra_functionality_.28bottom.29|Client Contact Rules]] section. You can add different forms of consent for different scenarios, and then use the Client Contact Rules feature to record whether that consent has been obtained or not.
| |
| − | | |
| − | | |
| − | [[File:SS_71.png|border]]
| |
| − | | |
| − | | |
| − | ====Contact Types====
| |
| − | | |
| − | Contact Types are an extra level of categorisation, separate to Communication Methods. For example, as well as logging the communication method, you might want to categorise your contacts in one of the categories below:
| |
| − | | |
| − | [[File:SS_18.png|border]]
| |
| − | | |
| − | These Contact Types can be set by the user when recording a contact - see [[Recording_Contacts_(Administrator_guide)#Contact_Type|this page]] for details. The ability to enter a Contact Type from the Record a Contact screen also needs to be turned on for each Project you want them available for: see [[Projects_(Administrator_guide)#Contact_Types|this page]] for details of how to do this.
| |
| − | | |
| − | ====Courses & Qualifications====
| |
| − | | |
| − | This list of courses and qualifications is specifically for logging the experience and qualification of your organisation's [[Volunteers#Log_courses_and_qualifications_obtained_by_the_volunteer|volunteers]] or staff.
| |
| − | | |
| − | [[File:SS_19.png|border]]
| |
| − | | |
| − | Clicking on the name of a course/qualification will show its details, along with an option to say whether it is a course or a qualification. The Type which is set will govern whether it is available from the Courses link or the Qualifications link. For details of how to log these, click [[Volunteers#Log_courses_and_qualifications_obtained_by_the_volunteer|here]].
| |
| − | | |
| − | [[File:SS_20.png|border]]
| |
| − | | |
| − | ====Data Dictionary Fields====
| |
| − | | |
| − | The Data Dictionary fields are fields in Charitylog for which you can change the options available. Clicking the link will show you the available Data Dictionary Fields.
| |
| − | | |
| − | [[File:SS_21.png|border]]
| |
| − | | |
| − | Clicking on the name of one will let you enter new options. If you want to delete an option, blank out the line in question and click "Save Details".
| |
| − | | |
| − | [[File:SS_22.png|border]]
| |
| − | | |
| − | ====Disabilities====
| |
| − | | |
| − | This is the list of disabilities available on your system for logging clients and other people. This will be set up according to your pre-implementation spreadsheet, or with a default list if you do not provide a list. Commonly the list of disabilities used by voluntary organisations is one set at regional or national level to help reports from different organisations match one another.
| |
| − | | |
| − | ====Districts====
| |
| − | | |
| − | Together with Towns and Counties, Districts help categorise people according to where they live. Districts are slightly different to Towns and Counties in that there is no set way to use them (Town and County are usually pretty obvious, and trying to use them in a way that is non-standard can confuse clients and users). They are used differently according to the needs of different organisations, and often organisations based in cities use them differently to organisations based outside major towns/cities.
| |
| − | | |
| − | They are often used to categorise clients' locations by broad or vague areas. For example, an organisation based in a city might use them as shown below:
| |
| − | | |
| − | [[File:SS_23.png|border]]
| |
| − | | |
| − | Note the "Out of our funded area" option - some organisations are only funded to work within certain areas and using Districts in this way can help you report on specific areas, and make sure that you are not doing too much work in a non-funded area.
| |
| − | | |
| − | ====Ethnic Origins====
| |
| − | | |
| − | This is the list of ethnic origins available on your system for categorising clients and other people. When you first start using Charitylog, this will be set up according to your pre-implementation spreadsheet. You can change or add to it as you wish. | |
| − | | |
| − | ====Living Arrangements====
| |
| − | | |
| − | Living Arrangements can be used to categorise organisations and people.
| |
| − | | |
| − | [[File:SS_24.png|border]]
| |
| − | | |
| − | ====Marital Status====
| |
| − | | |
| − | Marital Status is used to categorise organisations and people.
| |
| − | | |
| − | [[File:SS_25.png|border]]
| |
| − | | |
| − | ====Membership/Skills Groups====
| |
| − | | |
| − | This list is a list of the groups, committees, skill areas, or interests which carers, staff, volunteers and trustees may either belong to or have. They are usually referred to as "Groups and Skills". There are many places that they can be used in the system, and so the list you enter here may be quite diverse - there's nothing wrong with this. A common set of Groups and Skills might be set up to do with the various volunteer roles that your organisation might need. Creating Groups and Skills for volunteers such as "Befrienders", "Gardeners" and so on will enable users to look within these categories when assigning volunteers to clients.
| |
| − | | |
| − | [[File:SS_26.png|790px|border]]
| |
| − | | |
| − | ====Organisation and People Categories====
| |
| − | | |
| − | These are reporting categories used for Organisations and People. You can use any list of categories you want - it simply depends on what you want to report on. For instance, if it would be useful to know "how many referrals we have had over the year from GP surgeries", you would need a category called "Surgeries" that you put all of the GP surgeries into. The categories can also cross other divides - for example, you could have a category of "Health Groups" which includes voluntary organisations, paid-for health clubs and classes, gyms, and so on. These categories are usually used to categorise Organisations and Referrers, but you can also use them to categorise Staff, Volunteers and Suppliers.
| |
| − | | |
| − | [[File:SS_27.png|border]]
| |
| − | | |
| − | ====Referral Sources====
| |
| − | | |
| − | Referral Sources are separate to Referrers themselves - rather, they are used to capture data about where somebody heard about the services of the organisation. Users can enter a Referral Source (as well as a Referrer) on the Record a Contact screen. If you want this to happen, you need to enable it in [[Projects_(Administrator_guide)#Referral_Sources|the setup of each Project]].
| |
| − | | |
| − | [[File:SS_28.png|border]]
| |
| − | | |
| − | ====Relationships====
| |
| − | | |
| − | Relationships has options for Personal Relationships and Carer Relationships. They are used in two places - from [[Organisations_And_People#Relationships_Screen|the Relationships screen]], and as part of [[Carer_Assignments#Assigning_Carers|Carer Assignments]].
| |
| − | | |
| − | When entering new matching relationships, remember that you need to enter the relationship in both directions - for example, if you enter a "Husband" relationship, you will also need to enter a "Wife" relationship to be used for the other person.
| |
| − | | |
| − | [[File:SS_29.png|border]]
| |
| − | | |
| − | ====Religions====
| |
| − | | |
| − | The list of religions available on your system for logging people's details.
| |
| − | | |
| − | ====Service User Groups====
| |
| − | | |
| − | Service User Group is intended for grouping people together for reporting purposes - beyond that there are no specific ways you "should" use Service User Groups, so you can use them for anything you need.
| |
| − | | |
| − | ====Sexual Orientations====
| |
| − | | |
| − | The list of sexual orientations available on your system.
| |
| − | | |
| − | ====Status====
| |
| − | | |
| − | Like Service User Group, Status is a flexible field that you can use for anything you need.
| |
| − | | |
| − | ====Termination Reasons====
| |
| − | | |
| − | These are the reasons you can attach when you terminate a client's involvement with a Project. For more details about "Clients In Project" and Termination, see [[Projects_(Administrator_guide)#Clients_In_Project|this page]].
| |
| − | | |
| − | ''Unless you are certain that you need to make use of it, it is better to ignore the concept of Clients In Project and Termination.''
| |
| − | | |
| − | ====Town Lookup Edit====
| |
| − | | |
| − | Town Lookup Edit provides a way to fill out the Town, County and Postal District fields quickly and easily. You can set up Towns, and for each Town, associate a County and a District. Users can then select the correct Town when entering information to the system, and the County and District fields will automatically be filled in.
| |
| − | | |
| − | [[File:SS_30.png|border]]
| |
| − | | |
| − | If you are using Postcode Anywhere, this will override Town Lookup Edit.
| |
| − | | |
| − | ====Town Lookup Edit tutorial====
| |
| − | | |
| − | {{#ev:youtube|n3qr7mcmG9o|800}}
| |
| − | | |
| − | ==Equipment==
| |
| − | | |
| − | This menu item lets you set up pieces of equipment which can then be logged as loaned out to people. It is useful if your organisation provides equipment like laptops, accessible hardware and so on. You can also use it to log equipment that is provided to staff. Assignments can be made by way of the "Equipment" link which shows at the bottom of a Client's Details screen (ditto any other person type).
| |
| − | | |
| − | [[File:SS_31.png|border]] | |
| − | | |
| − | ==Equipment History==
| |
| − | | |
| − | This is a report to show what equipment assignments were made and when. You can specify a date range, enter part/all of the name of the piece of equipment if you want to report on something specific. You can then opt to show the results on screen (Display/Print) or download an Excel spreadsheet to your computer (Export).
| |
| − | | |
| − | [[File:SS_32.png|border]]
| |
| − | | |
| − | ==Extended Orgs & People List==
| |
| − | | |
| − | The Extended Orgs & People List is an Administrator-only search, which searches all of the Organisations and People on your Charitylog system at the same time. This is the only search where this is possible; all of the searches that end users can carry out are limited to one Type. A series of options for narrowing the search are available, as shown. If you wish, you can search only one Type.
| |
| − | | |
| − | [[File:SS_33.png|border]]
| |
| − | | |
| − | There are some particularly useful features to this search. In the results, you can set Organisations' Info Links by clicking the "Info Links" button.
| |
| − | | |
| − | [[File:SS_34.png|border]]
| |
| − | | |
| − | The search also shows on the results which Type(s) is/are associated with each Person or Organisation. Clicking on the name of one of the results will let you see the list of available Types in one column, with the option to select as many as required.
| |
| − | | |
| − | [[File:SS_35.png|border]]
| |
| − | | |
| − | ==Information Links Headings==
| |
| − | | |
| − | Information Links are covered in the [[Office_Functionality_(Administrator_guide)#Information_Links|Office Functionality]] chapter.
| |
| − | | |
| − | ==LSOA Areas and Wards==
| |
| − | | |
| − | Super Output Areas (SOAs) are a national geography created by the Office for National Statistics (ONS) for collecting, aggregating and reporting statistics. Using this feature in Charitylog, you can have postcodes "drive" selection of MSOA, LSOA, Ward, Locality and Local Authority. You would not want to set this up from scratch, as the list of postcodes even for a small geographical area would be very large. Rather, if you want to use SOAs, you will probably already have a strategy for getting the SOAs that cover your area. You can then provide a spreadsheet to Charitylog with all of these postcodes and associated SOAs, which can then be added to reports. Note that the LSOA and MSOA are not stored on the client record, but when you export a report with SOA data attached, the system puts together the client's postcode with the SOA table and adds the SOA data to the exported spreadsheet.
| |
| − | | |
| − | ''We do have a feature in development to enable postcodes to drive selection of everything else - ward, postal district, county and so on. This would replace/incorporate the functionality of Town Lookup Edit, Postcode Anywhere, and SOAs. This system is likely to take a while to develop, but please give us a ring on 01989 763 691 if you would like to discuss this proposed feature, and/or feed into the development discussion.''
| |
| − | | |
| − | ==Projects and Referral Entries==
| |
| − | | |
| − | Projects are a fundamental concept within the Charitylog system. They are covered in a separate chapter: [[Projects_(Administrator_guide)|Projects]].
| |
| − | | |
| − | ==Referral Reasons==
| |
| − | | |
| − | Referral Reasons are a set of reasons that can be attached to referrals. The unique aspect of Referral Reasons is that you have control over which Projects they are used for, so each Project can have their own set, if required. Optionally, users can also enter multiple reasons. Clicking the menu item will show you the list of Referral Reasons set up on your system, if there are any, along with the Projects they are associated with.
| |
| − | | |
| − | | |
| − | [[File:SS_37.png|border]]
| |
| − | | |
| − | | |
| − | Clicking on the name of the reason, or clicking the "Create New Reason" button, will let you edit the name of the reason and which Projects it is available to.
| |
| − | | |
| − | If you want to classify your referrals with more details than Referral Reasons will allow, you might like to consider using [[Classification Codes]].
| |
| − | | |
| − | ==Staff Time Splits==
| |
| − | | |
| − | | |
| − | ----
| |
| − | | |
| − | | |
| − | ==Security==
| |
| − | | |
| − | ====Classification Codes====
| |
| − | | |
| − | The coding system is a way of classifying activity. It is a hierarchical structure, so selecting a certain option in level 1 then gives sub-options in level 2, and sometimes there is a third level, a fourth, and so on. This diagram shows an example, with a Residential Care code grouping. Each option picked has an associated code, which is automatically added to the referral. When the user has selected an option in each level, the final code output is created and added to the details of the referral.
| |
| − | | |
| − | The arrows show the available paths to take. The red arrow shows the path actually taken, down to the final code creation: B2E, which actually means "Personal Expenses Allowance, within the Payment and Charging section of Residential Care".
| |
| − | | |
| − | | |
| − | [[File:SS_38.png|border]]
| |
| − | | |
| − | | |
| − | You can create your own code groupings like this - use the "Create New Code Grouping" button to make a new system.
| |
| − | | |
| − | | |
| − | [[File:SS_39.png|border]]
| |
| − | | |
| − | | |
| − | ...and once you have created your new code grouping, click "Edit" to be taken to the main codes entry screen.
| |
| − | | |
| − | | |
| − | [[File:SS_40.png|border]]
| |
| − | | |
| − | | |
| − | Once a main code is created, you can then create further sub-codes within it, with the "Go To Sub-Code" button....
| |
| − | | |
| − | | |
| − | [[File:SS_41.png|border]]
| |
| − | | |
| − | [[File:SS_42.png|border]]
| |
| − | | |
| − | | |
| − | ...and you can add further sub-codes '''within that sub-code'''...
| |
| − | | |
| − | | |
| − | [[File:SS_43.png|border]]
| |
| − | | |
| − | [[File:SS_44.png|border]]
| |
| − | | |
| − | | |
| − | ...and so on.
| |
| − | | |
| − | '''Note''' that you can give your own code system as many levels as you need, but consider how easy (or otherwise) it will be for day-to-day users to enter the codes. It's best to keep any coding system as streamlined as possible.
| |
| − | | |
| − | ===Questions attached to codes===
| |
| − | | |
| − | At each level of the classification coding system, you have the option to add a question if a certain option is picked. When the users selects that option, a field will appear for entry of an answer to a question.
| |
| − | | |
| − | Click on the name of a sub-code:
| |
| − | | |
| − | | |
| − | [[File:SS_58.png|border]]
| |
| − | | |
| − | | |
| − | Then click the "Save and Enter Questions" button.
| |
| − | | |
| − | | |
| − | [[File:SS_57.png|border]]
| |
| − | | |
| − | | |
| − | You can now enter a question to associate with the code. In this case, a question has been added to a "Bus Timetables" code, which will ask the client for the date they started using the bus in preference to a car. Click "Save Details" when complete.
| |
| − | | |
| − | | |
| − | [[File:SS_59.png|border]]
| |
| − | | |
| − | | |
| − | You will now be returned to the question display screen, with your new question shown.
| |
| − | | |
| − | | |
| − | [[File:SS_60.png|border]]
| |
| − | | |
| − | | |
| − | When a user picks this code, a date entry box will appear below it for an answer to be entered.
| |
| − | | |
| − | | |
| − | [[File:SS_61.png|border]]
| |
| − | | |
| − | | |
| − | ====When to use codes====
| |
| − | | |
| − | * Using classification codes is good when you want a hierarchical structure. It is particularly useful if you have a large amount of possible codes that you want to use - breaking them down into levels like this means it is easy for end users to select from even a very large list of codes, without actually having to know the codes in the first place. They can simply pick the appropriate code in level 1, then pick the most appropriate code from level 2, and so on.
| |
| − | * Codes are also useful because you can log several codes against each contact, and therefore against each referral. In a project where you discuss a wide range of issues with a client at one visit, this can be a useful way to log all of these at once. This would not be allowed by Referral Reasons etc.
| |
| − | * Finally, code entry can be optional or forced - so forcing code entry will ensure that something is entered against each referral.
| |
| − | | |
| − | ====When not to use codes====
| |
| − | | |
| − | Against the above points, you should balance the following -
| |
| − | | |
| − | * Forcing code entry puts in another step to the process of recording contacts. Codes can be very useful, but using them when they are not really needed can add unnecessary hassle to an end user's day-to-day work.
| |
| − | * Only use codes if you have a general reporting need for that level of detail. If you do not need great detail, you may be able to use Referral Reasons, Project Subcategories or an Extension Database on referral entries. | |
| − | | |
| − | ==Anonymise Clients==
| |
| − | | |
| − | The "Anonymise Clients" menu item is a specific search used, as the name suggests, for wiping personal data from details of clients who will have no more dealings with your organisation. You might choose to anonymise clients for various reasons - if they have died, moved away etc. More likely, it is because that individual has had no dealings with your organisation for a predefined period - for example, 7 years - and your data protection policy requires you to turn their data into a form which cannot identify individuals and where identification is not likely to take place. The "Anonymise Clients" feature allows you to do this, whilst retaining important data for your historical reports.
| |
| − | | |
| − | Clicking on the "Anonymise Clients" menu item will show you a search form:
| |
| − | | |
| − | | |
| − | [[File:SS_45.png|border]] | |
| − | | |
| − | | |
| − | This search will only show clients who are not active, and have had all their involvement with Projects terminated. Once you have found the clients you need, you can anonymise them.
| |
| − | | |
| − | For more details about active and non-active Clients, click [[here]].
| |
| − | For more details about terminating a Client's involvement with a Project, click [[here]].
| |
| − | | |
| − | ==Backup==
| |
| − | | |
| − | The "Backup" menu item has two functions. | |
| − | | |
| − | ===Backup of your database===
| |
| − | | |
| − | This will allow you to download a complete copy of your data from the system. You do not need to use this in day-to-day activity, as all data is securely backed up by the data centre. This menu item is to be used in the event of your system becoming unsupported. We have a copy of our source code held by a solicitor. In the event of Charitylog becoming unsupported, you will be able to obtain a copy of our source code. By putting this together with a backup from your system, you will be able to restore your data and carry on working.
| |
| − | | |
| − | This backup cannot be used without the source code. If you need to get figures and data out of your Charitylog system for reporting purposes, you can do so using the [[Reports]] menu item.
| |
| − | | |
| − | ===Backup of uploaded documents===
| |
| − | | |
| − | You can also download a compressed copy of all of the Uploaded Documents that have been stored on your Charitylog system.
| |
| − | | |
| − | ==Customisable Tab Settings==
| |
| − | | |
| − | This menu item allows you to control which data fields are shown on the General Details and Personal Details tabs of Organisation/People records. Using these, you can decide exactly what data will be shown, field by field.
| |
| − | | |
| − | * This can be put together with the following features to gain fine control of data visibility. | |
| − | ** User Settings - Personal Tab Access and Project Visibility
| |
| − | ** User Generated Org/People Types
| |
| − | | |
| − | If you need help configuring these parts of the system, please speak to your Implementation Consultant, or call our support line on 01989 763 691.
| |
| − | | |
| − | ==Delete Referrals==
| |
| − | | |
| − | To be used when users have entered incorrect data, or entered data twice.
| |
| − | | |
| − | '''Use with extreme caution - in case of double entry, make sure all data to be kept has been transferred to the Referral which will survive. We advise that you only use the Delete Referrals feature under specific guidance from us.'''
| |
| − | | |
| − | ==Extension Databases==
| |
| − | | |
| − | Extension Databases provide a way of adding to your Charitylog system, if you find that the standard setup doesn't quite do what you want. They can be used in all sorts of different ways - you can create them:
| |
| − | | |
| − | * To appear on every Client Details screen (or indeed on any Details screen required)
| |
| − | * To appear on the Client Personal Details tab (so you can restrict view access to them if required)
| |
| − | * To appear on a Club or Clinic Details screen
| |
| − | * To appear after recording a contact - either once per chain of actions, or after every action in the chain
| |
| − | | |
| − | You can use them in the following ways:
| |
| − | | |
| − | * Store extra data about organisations or people
| |
| − | * Store extra data about clubs or clinics
| |
| − | * Run reports on them using [[Extension Database Reports]]
| |
| − | * Include them with other reports as part of the [[KPI Report Designer]]
| |
| − | * and more! | |
| − | | |
| − | Extension Databases are covered in their own chapter: [[Extension_Databases_(Administrator_guide)|Extension Databases]].
| |
| − | | |
| − | ==External Referral Settings==
| |
| − | | |
| − | This menu option relates to the [[Referral Portals Module]].
| |
| − | | |
| − | ==Help==
| |
| − | | |
| − | The Help section contains the following.
| |
| − | | |
| − | ===FAQs===
| |
| − | | |
| − | Frequently Asked Questions about the Charitylog system.
| |
| − | | |
| − | ===Documentation and Guides===
| |
| − | | |
| − | Downloadable help documentation. In time, this will be replaced by this manual.
| |
| − | | |
| − | ===System Updates===
| |
| − | | |
| − | Updates that have been made to your Charitylog system, along with details of new features etc.
| |
| − | | |
| − | ===Support===
| |
| − | | |
| − | The Support Ticket feature is under development. It allows you to generate a support ticket to be sent to us, and also allows you to generate a key so that a Charitylog help team member can share your screen to solve problems.
| |
| − | | |
| − | ==Input Field Rules==
| |
| − | | |
| − | Input Field Rules are an important way to streamline data input to your Charitylog system.
| |
| − | | |
| − | ===Standard Input Field Rules===
| |
| − | | |
| − | Users should always start the process of recording a contact with a search for the person in question (usually a Client). This is to make sure that the person in question is not already entered to the system (and remember that because the whole organisation is sharing a data pool, it is quite possible that the person in question has been entered by a different service within the organisation). If the person is already on the system, they can check the History tab, see if the referral is already started, and if so, carry on from there. If the person is not on the system, they can then use a "Create New" button to make a new client/volunteer/etc.
| |
| − | | |
| − | At this point, they are taken to a blank record for editing. In the case of a Client, the blank record looks like this.
| |
| − | | |
| − | | |
| − | [[File:SS_46.png|790px|border]]
| |
| − | | |
| − | | |
| − | As you can see, there are a lot of fields available (and there are actually twice as many as shown, because there is a Personal Details tab available too). Seeing this amount of data entry can easily put off an end user. Furthermore, the user has no way of knowing what the organisation's policy is on data capture - so some staff members may take down a lot of details, while others only record a name.
| |
| − | | |
| − | Input Field Rules solves this problem. You can set up a set of rules for a general, organisation-wide minimum data set. This will create a new button on a client search result, "Record a Contact for a New Client".
| |
| − | | |
| − | [[File:SS_47.png|border]]
| |
| − | | |
| − | Rather than go to a full client record for editing, this will take a user to a screen with a data entry form which will be driven by the Standard Input Field Rules. So if the Standard Input Field Rules are set to require a (sur)name, forename(s) and a postcode, the data entry screen you will see will look like this:
| |
| − | | |
| − | | |
| − | [[File:SS_48.png|border]]
| |
| − | | |
| − | | |
| − | This is much more palatable to an end user than a full, blank client record.
| |
| − | | |
| − | The system-wide (Standard) Input Field Rules are set up by clicking the "Input Field Rules" menu item, then the "Edit Rules" link:
| |
| − | | |
| − | | |
| − | [[File:SS_49.png|border]]
| |
| − | | |
| − | | |
| − | This will take you to a screen where you can set any of the data to be stored with one of four options -
| |
| − | | |
| − | * No Rules
| |
| − | * Show on entry screen (but allow to be left empty)
| |
| − | * Warning if not filled in
| |
| − | * Must be filled in | |
| − | | |
| − | | |
| − | [[File:SS_50.png|border]] | |
| − | | |
| − | | |
| − | '''Use "Warning if not filled in" with caution.''' Setting a field to this option will show the box in yellow on the data entry screen, and if the user tries to save details without entering any data in that box, they will be shown a popup warning for that box. If there are several boxes set as "Warning if not filled in", the user will be shown several warning popups, which can be quite cumbersome.
| |
| − | | |
| − | ===Project-Specific Input Field Rules===
| |
| − | | |
| − | Standard Input Field rules are effective, but they are not enough to deal with the varying data capture needs of a whole organisation. More often than not, the different projects within one organisation will have different requirements, for example -
| |
| − | | |
| − | * As well as standard data, the Information service needs to know clients' telephone number, email address, and preferred method of communication.
| |
| − | * As well as standard data, the Housing Support service needs to know clients' living arrangements, employment status and whether they have a disability. | |
| − | | |
| − | ...and so on. Incorporating all of these requirements into the Standard Input Field Rules would be tiresome, and would mean that each Project has to capture data for the sake of other Projects. This will lead to increased workload and pressure on staff, so must be avoided. Instead, you can use Project-Specific Input Field Rules to deal with these requirements. Click on the "Input Field Rules" menu item. At the bottom of the page are the Input Field Rules for each Project.
| |
| − | | |
| − | | |
| − | [[File:SS_51.png|border]] | |
| − | | |
| − | | |
| − | Click "Create Rules" next to the Project you want to set the Input Field Rules for. You will see a similar screen to that which is displayed for standard rules.
| |
| − | | |
| − | | |
| − | [[File:SS_52.png|border]]
| |
| − | | |
| − | | |
| − | Shown above is the example scenario for the Information project, requiring "Preferred Method of Communication", "Main Telephone No." and "Email Address (Main)" to be filled in. These Input Field Rules are added to the standard rules, so you do not need to set "Surname", "Forename" and "Postcode" as required in the project specific rules - they will be carried over from the standard rules.
| |
| − | | |
| − | If you now use "Record a Contact for a New Client", and enter the required (Standard) details...
| |
| − | | |
| − | | |
| − | [[File:SS_53.png|border]] | |
| − | | |
| − | | |
| − | ...and click "Save Details", you can then pick the Project to be used, in the usual way. In this case, "Information" is selected. The system then checks the Project specific Input Field Rules, and if there is data not yet stored on this client, you will be prompted for it.
| |
| − | | |
| − | | |
| − | [[File:SS_54.png|border]]
| |
| − | | |
| − | | |
| − | [[File:SS_55.png|border]]
| |
| − | | |
| − | | |
| − | In this way, each Project can require its own data set, without burdening all other Projects with its requirements.
| |
| − | | |
| − | ===User Group Specific Input Field Rules===
| |
| − | | |
| − | You can also apply a set of Input Field Rules to any User Group set up on your system.
| |
| − | | |
| − | | |
| − | [[File:SS_56.png|border]]
| |
| − | | |
| − | | |
| − | Just like Project-specific Input Field Rules, these are added to the Standard (and Project if used) Input Field Rules. You cannot use Group-specific Input Field Rules to allow groups to enter less data than standard, only more.
| |
| − | | |
| − | ===Applying Standard Input Field Rules to the Client Record===
| |
| − | | |
| − | There is another place that Input Field Rules appear - in [[Operational Rules]]. There is a field which lets you set your system to apply the standard Input Field Rules to the [[Client Record]] itself. Use with caution, as it can slow/frustrate data entry, but if you want your users to be prompted frequently to preserve the data you store for clients, it's there if you need it.
| |
| − | | |
| − | | |
| − | [[File:a_system_ifr_1.png|border]] | |
| − | | |
| − | ===Input Field Rules for anonymous contacts===
| |
| − | | |
| − | Recording anonymous contacts has a slightly different relationship to Input Field Rules - namely that recording of anonymous contacts will not function until you have set up some Input Field Rules to suit. To create some Input Field Rules, click the "Create Anon. Rules" link as shown:
| |
| − | | |
| − | | |
| − | [[File:A_rac_1.png|border]]
| |
| − | | |
| − | | |
| − | '''Even if you don't enter a requirement for the "Name" field, it will appear on anonymous contacts anyway.''' Although it seems a bit silly to require a name from an anonymous contact, this field is important for two reasons:
| |
| − | | |
| − | * Recording an anonymous contact doesn't just "lose" the person; rather, it does create a client on the system, and that client is named "Anonymous Client". Over time, a lot of anonymous contacts will create a lot of clients with the same name. This isn't ideal, but it does mean that if a client who was previously anonymous comes back to have some work done with your organisation, you at least have some chance of finding the relevant anonymous contacts and merging the client records. Creating a new client each time also means that your reports for "how many client contacts have we had" will have the correct numbers in.
| |
| − | * This field, when used for Recording an Anonymous Contact, allows the end user to look up surnames on the system and check that the client is not, in fact, already on the system. This commonly happens when clients have involvement with one project more than others - they may not realise that everyone is using the same database.
| |
| − | | |
| − | | |
| − | [[File:rac_anon_1.png|border]]
| |
| − | | |
| − | | |
| − | [[File:rac_anon_2.png|border]]
| |
| − | | |
| − | ==Insert Audit Report==
| |
| − | | |
| − | The Insert Audit Report (also called the Record Insert Audit Report) is a feature which can show you all submissions made to the database either by a particular user, to a particular table, or both.
| |
| − | | |
| − | Use only under guidance from Charitylog.
| |
| − | | |
| − | ==Integrated Add-on Software==
| |
| − | | |
| − | eziTracker Settings
| |
| − | | |
| − | Postcode Anywhere Settings
| |
| − | | |
| − | Text Anywhere Settings
| |
| − | | |
| − | ==Make Assessment Forms==
| |
| − | | |
| − | Assessments is covered in its own chapter: [[Assessments_(Administrator_guide)|Assessments]].
| |
| − | | |
| − | ==Operational Rules==
| |
| − | | |
| − | ===Client Record Rules===
| |
| − | | |
| − | * '''Force Client Telephone Number Entry?'''
| |
| − | * '''Force Client Address Line 1 Entry?'''
| |
| − | * '''Force Client Postcode Entry?'''
| |
| − | * '''Force Status Entry?'''
| |
| − | | |
| − | These four options relate to the Client Details screen. They can be used to help ensure data is captured. If enabled, each will force the relevant field to become a "must be filled in" field. When a user views the Client Details screen, if they try and save a record without the relevant field filled in, the system will pop up a warning box and will not let them save the record without the relevant information. Essentially it makes sure that no client can be active on the system at all without this piece of information. In this way it is even more universal than the Standard Input Field Rules (which only apply when recording a contact). It can be a burden to users, so should be used with caution, but it can be effective.
| |
| − | | |
| − | ====Force "Check for Duplicates" Button Use?====
| |
| − | | |
| − | Setting this to "yes" will mean that a user is not permitted to create a new client on the system without having first used the "Check for Duplicates" button.
| |
| − | | |
| − | ====Use Standard "Input Field Rules" validation on Client Records?====
| |
| − | | |
| − | Setting this to "yes" wil apply the Standard Input Field Rules to every client details screen, so the data capture requirements will be imposed every time a user saves a client record. Like the first four options on this tab, this option should be used with caution.
| |
| − | | |
| − | ====Use People/Organisation ID as Account Code====
| |
| − | | |
| − | Setting this to "yes" will carry someone's unique Charitylog ID number into their Accounts Code field on the "Client Details" screen, in order to create invoices for them from the [[Accounts_Module_(Administrator_guide)|Accounts Module]]. You may be given accounts codes by your funders, or you may already have them created - but if not, using Charitylog IDs to do so is a neat solution.
| |
| − | | |
| − | If using this option, it will not simply go through the system and fill all boxes in - you will need to go to each record and manually re-save it (using a "Save Details" button or the equivalent). This will create the code.
| |
| − | | |
| − | ====Prefix for Account Code (If Using Org IDs)====
| |
| − | | |
| − | This relates to the above option. If "Use People/Organisation ID as Account Code" is set to "Yes", this prefix will be added to the automatically created accounts codes.
| |
| − | | |
| − | ====Limit GPs and Surgeries by District?====
| |
| − | | |
| − | If set to "Yes", this will mean that once a District is set on the Client Details screen, the only GP Surgeries and GPs available to be selected on the "Personal Details" tab for that client will be those GPs and Surgeries also located in that District.
| |
| − | | |
| − | This is good if your organisation covers a large, densely populated area with a lot of Surgeries, in which case the selection list would become long if not limited by District. On the other hand, it will make it more difficult to record the fact that a client might attend a Surgery or see a GP who is outside their District of residence.
| |
| − | | |
| − | ====Override Default Limit For Number Of Contacts In History Tab?====
| |
| − | | |
| − | Selects whether or not to make the History tab (on Organisation and People records) as long as it could possibly be, even if the org/person has many contacts here, or limit it to a system-wide setting (currently 200).
| |
| − | | |
| − | ====Maximum Number of People/Organisation Results Before Search Is Shown====
| |
| − | | |
| − | This setting governs how long a list can be before the user is prompted to run a search. For example, if this number is set to "5", and you only have four clients on your system, when a user clicks the "Clients" link, they will simply see a list of those four clients. However, if you have six clients or more on your system, when a user clicks the "Clients" menu item they will be shown a search form instead, prompting them to run a search for the client.
| |
| − | | |
| − | Although the screen is big enough for lists to become fairly long, you are advised to keep this number low. The sooner users are prompted to search the existing data, the better - this decreases the chance of any Organisations/People being duplicated on the system. Indeed, you may choose to set this number to zero from the start of your use of the system, meaning that users will always be given a search box rather than seeing a list.
| |
| − | | |
| − | ===RaC/New Referrals Rules===
| |
| − | | |
| − | ====Force "Communication Method" on Record a Contact / Referral Details?====
| |
| − | | |
| − | Setting this option to "yes" will mean that users cannot record a contact without specifying what the communication method was (telephone, office visit etc - set up from a [[Drop-Down List]].
| |
| − | | |
| − | ====Disallow alteration of User Name on Record a Contact / Referral Details?====
| |
| − | | |
| − | Setting this option to "yes" will mean that users cannot change the "Done By" name on Record a Contact - i.e. users will only be able to log work for themselves; they will not be able to fill in Charitylog for someone else's action and log it against that person.
| |
| − | | |
| − | ====Allow entry of "Represented By" (second referrer name) on Record a Contact?====
| |
| − | | |
| − | This will show an extra box on Record a Contact, "Represented By", where the user can record if a client was accompanied by someone - family member, health professional etc. The field is not subject to any validation and is simply for text, so for reporting needs, this is best avoided.
| |
| − | | |
| − | ====Allow Project To Be Changed On Referral Edit?====
| |
| − | | |
| − | If you are editing a Referral after it has been entered (which we do not advise apart from in specific circumstances) this will allow you to change the Project that the Referral is logged under.
| |
| − | | |
| − | ====Allow entry of "Contact With" on Actions?====
| |
| − | | |
| − | Setting this option to "Yes" will display a "Contact With" box on actions, which can be filled in with any Referrer. This is useful if you do work on behalf of a client, and deal with other organisations. Note that the "Contact With" box will not show on the initial contact entry.
| |
| − | | |
| − | ====Allow use of "Priority" ratings on Actions====
| |
| − | | |
| − | Setting this option to "Yes" will allow users to log outstanding actions as "High Priority" or "Normal".
| |
| − | | |
| − | ===Security Rules?===
| |
| − | | |
| − | ====Keep an audit of Record Inserts?====
| |
| − | | |
| − | Sets whether or not to keep details of who has edited records in your database, which feeds into the [[#Insert Audit Report|Insert Audit Report]].
| |
| − | | |
| − | ====Keep an audit of Page Visits?====
| |
| − | | |
| − | Sets whether or not to keep details of who has visited pages. You should leave this set to "Yes", although at the moment this is only used by our programming team for diagnostics.
| |
| − | | |
| − | ====Limit Staff Timesheet Access to====
| |
| − | | |
| − | Sets whether users can view all timesheets, or only edit their own.
| |
| − | | |
| − | ====Password-related options====
| |
| − | | |
| − | These are self explanatory.
| |
| − | | |
| − | ===Miscellaneous Rules===
| |
| − | | |
| − | ====Sending Emails: Review Emails Before Sending?====
| |
| − | | |
| − | Selects whether to send emails immediately or let users preview them before sending.
| |
| − | | |
| − | ====Start and End Time of Working Day====
| |
| − | | |
| − | These are used by the calendars in Charitylog, with the default start time being the office start time for each day, and for the default time on an outstanding action in the Record A Contact screen. It is also used for Support Workers default working day automatic entry.
| |
| − | | |
| − | ====Consent Text (Consent Help Button on Client Record)====
| |
| − | | |
| − | This text will be displayed if a user clicks the "help" icon next to the "Consent Given" box on a Details screen (for an Organisation or Person). This is ideal for writing in a prepared script for users to read to clients, making sure they understand how you will use their data.
| |
| − | | |
| − | ====Email Footer (Company Information) Legal Text====
| |
| − | | |
| − | This text, if entered, will appear at the bottom of system generated emails under a horizontal rule. It does not override the standard footer set up on that letter template, but appears in addition to it - the standard footer will be above the horizontal rule, and the legal text will be below.
| |
| − | | |
| − | ===Changing Menu Order===
| |
| − | | |
| − | Once you have finished working with Operational Rules, you may notice that there is an extra button across the bottom of the "Operational Rules" screen, "Save Details and go to Menu Order" - as shown:
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_1.png|border]]
| |
| − | | |
| − | | |
| − | The screen which follows allows you to change the order and structure of the main Charitylog menu, which all users see down the left hand side of the page. The most common reason to change the standard menu is to make your most frequently used options accessible, and to make using the system easier.
| |
| − | | |
| − | After clicking the "Save Details and go to Menu Order" button, you will be taken to the "Menu Option Structure" screen.
| |
| − | | |
| − | | |
| − | [[File:menu_option_structure.png|800px|border]]
| |
| − | | |
| − | | |
| − | The columns show the following:
| |
| − | | |
| − | * '''The first number''' is a number associated with that menu item
| |
| − | * '''Option name''' - the name of the menu item
| |
| − | * '''Standard Program Section''' - where to find the menu item in the default menu setup
| |
| − | * '''Submenu Of Option Ref. Number''' - if this menu item is within a submenu, the number of that submenu heading will be shown here. The main menu itself is number 0, and any menu item with a 0 in this column is part of the main menu.
| |
| − | * '''Option Display Order In Section''' - the "weight" associated with that menu item. Items with the same weight will be ordered alphabetically. | |
| − | * '''Option Help Text''' - text entered here will become available as a pop-up help text box on the menu.
| |
| − | | |
| − | To demonstrate how to use all these, let's walk through the most common change to make to the menu structure; moving the "clients" link out of the "Organisations and People" submenu, and putting it at the top of the main menu.
| |
| − | | |
| − | This is how the menu looks as standard, with "Clients" located in the "Organisations and People" submenu:
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_4.png|border]] | |
| − | | |
| − | | |
| − | First we need to find the line associated with the "Organisations And People" submenu heading...
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_2.png|border]]
| |
| − | | |
| − | | |
| − | ...and also the one associated with the "Clients" menu item:
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_3.png|border]]
| |
| − | | |
| − | | |
| − | Notice that the "Organisations And People" submenu heading is in section 0, which is the main menu, and has the number 262.
| |
| − | | |
| − | The "Clients" link is in section 262 - '''that is, in the "Organisations and People" submenu'''.
| |
| − | | |
| − | We want to take the "Clients" link out of the "Organisations and People" submenu and put it at the top of the main menu. So all we need to do is to change the "Submenu Of Option Ref. Number" entry for "Clients" to 0...
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_5.png|border]]
| |
| − | | |
| − | | |
| − | ...and if we want it to always appear at the top of the main menu, we should change the "Option Display Order In Section" entry to 1 (giving the item a "weight" of 1, and making it rise to the top of the menu).
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_6.png|border]]
| |
| − | | |
| − | | |
| − | Now scroll to the very bottom of the page and click "Save Menu Order and Continue"...
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_7.png|border]]
| |
| − | | |
| − | | |
| − | ...and you should now see that your new menu order has become active, with "Clients" being displayed at the top of the main menu.
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_8.png|border]]
| |
| − | | |
| − | ==Making a new menu grouping==
| |
| − | | |
| − | Another common alteration to the menu is to create a new submenu, to keep the most commonly used menu items together.
| |
| − | | |
| − | To demonstrate this, let's make a new submenu called "Common Options", and put "Clients" and "Record an Anonymous Contact" in it. At the very bottom of the "Menu Option Structures" screen is a button, "Add New Menu Grouping".
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_9.png|border]]
| |
| − | | |
| − | | |
| − | Clicking this button will take you to a screen where all the standard submenus are displayed. You can now specify what the name of your new group is going to be, and whether it's going to belong in the main menu or within another submenu. We are going to head the new submenu "Common Options", and put it within the main menu.
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_10.png|border]]
| |
| − | | |
| − | | |
| − | Once these are filled in, click "Add New Grouping".
| |
| − | | |
| − | You will be taken back to the "Menu Option Structure" screen, where your new grouping will be displayed. You can now move it, or put other menu items in it, as before. Here's the new "Common Options" submenu, with "Clients" and "Record an Anonymous Contact" in it.
| |
| − | | |
| − | | |
| − | [[File:A_system_menu_11.png|border]]
| |
| − | | |
| − | ==Referral Closure Update==
| |
| − | | |
| − | This option will update all the Referral (Diary Entry) Closure dates in accordance with the preferences set against the Projects. If you have set 'Automatic Closure' to 'Yes', all Diary Entries will be checked and updated according to whether there are any outstanding Actions left or not. If it is set to 'No', no changes will be made to the Referral Closure Dates for Diary Entries in that Project.
| |
| − | | |
| − | ==Update Replica Databases==
| |
| − | | |
| − | This option lets you copy your live database to your test system, for training and experimenting.
| |
| − | | |
| − | ==User Login History==
| |
| − | | |
| − | This report will show which users have logged in to your Charitylog system and when, along with their IP addresses.
| |
| − | | |
| − | ==User Settings==
| |
| − | | |
| − | ===Group Access===
| |
| − | | |
| − | The Group Access screen allows administrators to control what each [[User Groups|User Group]] has access to throughout the Charitylog system. It is one of the most powerful tools that administrators have in running the system, and is covered in its own document here: [[User_Access_Management#Limiting_access_by_user_group|Group Access]].
| |
| | | | |
| | ===Users=== | | ===Users=== |
| | + | The next step is to determine the security groups that you need for your users. See [[Group Access]] for further details (Not available on Local, Members and Single Project systems). Once you have configured your required groups you can the setup the users and put them in the groups and specify which projects they work in. See [[Users]] for full details. |
| | + | Users |
| | | | |
| − | ====About Users and User Groups==== | + | ===Adding extra fields (Additional option for Local and Members System)=== |
| − | | + | From the fields that you have setup you may find that you require additional fields. These fields can be added to the tabs that you have configured or at the base of the record. The extension databases can be restricted by the [[Group Access]] groups setup. For further details see [[Extension Database Setup]]. |
| − | Users are the people who can actually log into your Charitylog system. They are not an Organisation/Person type - you can create a User who can log in without associating that User with any Org/Person. (Likewise, you can have an Organisation/Person who does not have an associated User record.)
| |
| − | | |
| − | More usually, though, a User will have an associated Organisation/Person record - most commonly a Staff member, but sometimes a Volunteer, Funder, Trustee or Referrer.
| |
| − | | |
| − | User Groups are set up to define how much access users have to the system. You can place the User in a User Group, and then configure the access rights for each group. Click on "Group Access", which will show you the groups active on your system.
| |
| − | | |
| − | | |
| − | [[File:SS_64.png|border]]
| |
| − | | |
| − | | |
| − | * To edit a group, click the "Alter Which Group?" button and then click "Set Group Access Rights".
| |
| − | * To create a new group, select the '''''Create New Group''''' button and click "Set Group Access Rights".
| |
| − | * To copy the access rights to your new group, first create the group, then return to this screen, select the group to copy access rights from, and click "Set Group Access Rights".
| |
| − | | |
| − | For more information on Group Access, please see the [[User_Access_Management#Limiting_access_by_user_group|User Access Management chapter]].
| |
| − | | |
| − | Clicking the Users menu item will show you a list of all users that are set up on your Charitylog system.
| |
| − | | |
| − | | |
| − | [[File:SS_65.png|border]]
| |
| − | | |
| − | | |
| − | Click on the name of a user to edit.
| |
| − | | |
| − | | |
| − | [[File:SS_62.png|border]]
| |
| − | | |
| − | | |
| − | There are now five tabs which hold all the information about this user.
| |
| − | | |
| − | ====General User Details tab====
| |
| − | | |
| − | | |
| − | [[File:SS_63.png|790px|border]]
| |
| − | | |
| − | | |
| − | * Full name
| |
| − | * User name
| |
| − | * Password (if you have access to the "Users" menu item, you can change passwords for Users)
| |
| − | * Change password at next login - if you tick this box and "Save Details", the user will be prompted to reset their password when they next log in.
| |
| − | * Telephone number
| |
| − | * Email address
| |
| − | * Group - the User Group that this User is to be placed in.
| |
| − | * Start Screen - the screen that this user will be directed to when they first log in. The Action List is the most common, but there are plenty of other options.
| |
| − | * General Display Style - as well as the standard, there are large print and high-contrast variations.
| |
| − | * Whether there is a link from this User to an Organisation/People record
| |
| − | * Is this User also a Handyperson? - select "Yes" to make them available to have Handyperson work assigned to them.
| |
| − | * Is this user a Referrer With Referrer Only Access - Select Referrer - this is a deprecated feature, and has been superseded by Pro-Referrers. It will be removed in a future release.
| |
| − | * Personal Tab and Project access rules - we will cover these later in this chapter.
| |
| − | * Active User? - you cannot delete Users, but you can make them inactive. This is usually done when a staff member leaves the organisation.
| |
| − | | |
| − | ====Referrals/Actions Settings tab====
| |
| − | | |
| − | | |
| − | [[File:SS_66.png|790px|border]]
| |
| − | | |
| − | | |
| − | =====Referrals Diary Defaults=====
| |
| − | Control this User's view of the Referrals Diary. The Referrals Diary is a legacy feature which will be deprecated in a future version.
| |
| − | | |
| − | =====Action List Defaults=====
| |
| − | Control how this User's Action List will appear. The user will still be able to change these options themselves at the top of their Action List, but these settings govern the default display. It is a good idea to set these defaults to whatever the Users find most useful - usually:
| |
| − | | |
| − | * Own Entries Only
| |
| − | * 7 days past and future
| |
| − | * View all contacts done plus outstanding actions
| |
| − | * Order by Action Date (descending) (newest at the top)
| |
| − | | |
| − | =====Client History ordering options=====
| |
| − | | |
| − | Choose how to order the History and Summary tabs on an Organisation/Person record for this user. Descending (newest at the top) is generally felt to be the most natural way for these to appear.
| |
| − | | |
| − | ===System Access tab===
| |
| − | | |
| − | | |
| − | [[File:SS_67.png|790px|border]] | |
| − | | |
| − | | |
| − | * Allowed to Merge Records? - choose whether this User will be allowed to merge clients, organisations, etc. together (if they have been entered twice in error).
| |
| − | * Allowed to Enter Project Sub-categories? - choose whether this user can add a Project Subcategory on the Record a Contact screen or not.
| |
| − | * Allowed to Delete Uploaded Documents? - on Organisation/Person records
| |
| − | * Allowed to Delete Next of Kin Records? - on client records
| |
| − | * Allowed to Delete Extension Database Records?
| |
| − | * Allowed to Create Private Notes? - on Organisation/Person records
| |
| − | | |
| − | =====Login times=====
| |
| − | | |
| − | These can be used to govern when this User can log in. Usually there is no need to restrict login times.
| |
| − | | |
| − | * Allowed to use Favourites? - see [[Office_Functionality#Favourites|Favourites]] for more information.
| |
| − | * Copy Favourites from Another User - use when setting up new users, to copy in Favourites settings (can speed up user entry)
| |
| − | * Copy Access Rights from Another User - use when setting up new users, to copy in Project/Personal Tab access settings (can speed up user entry)
| |
| − | | |
| − | ===Project Access tab===
| |
| − | | |
| − | | |
| − | [[File:SS_68.png|790px|border]]
| |
| − | | |
| − | | |
| − | See [[User_Access_Management#Project_Access_tab|the User Access Management chapter]] for details of how the Project Access tab operates.
| |
| − | | |
| − | ===Personal Tab Access tab===
| |
| − | | |
| − | | |
| − | [[File:SS_69.png|790px|border]] | |
| − | | |
| − | | |
| − | See [[User_Access_Management#Personal_Tab_Access_tab|the User Access Management chapter]] for details of how the Personal Tab Access tab operates.
| |
| − | | |
| − | ===Courses and Qualifications===
| |
| − | | |
| − | You can log [[System_Setup_Guide#Courses_.26_Qualifications|Courses and Qualifications]] that this user has gained with the links at the bottom of the "User Account Details" screen, just above the "Save Details" button:
| |
| − | | |
| − | | |
| − | [[File:SS_70.png|border]]
| |
| − | | |
| − | | |
| − | ----
| |
| − | | |
| − | [[File:helpheader_small.png|left]]
| |
| − | | |
| − | <div style="text-align:right;">
| |
| − | ''This concludes the System Setup Guide.''
| |
| − | | |
| − | ''Click to go back to the '''[[Main_Page#Administrator_Manual|Administrator Manual]].'''''
| |
| | | | |
| − | ''Click to go to the next section, '''[[User Access Management]].'''''
| + | ===Other (Additional features for Members system)=== |
| − | </div>
| + | From here you may wish to add Organisations and Referrers to the system, see: |
| | + | * [[Organisations and People]] |
| | + | * [[Organisations]] |
| | + | * [[Referrers]] |
The system is designed to be customisable for each organisation that uses it. Before you get going you will be provided a pre-implementation spreadsheet to complete, from this a system is created. This guide will talk you through the various steps that are needed to get your system set-up.
The pre-implementation spreadsheet is used to save time on the first day of setting up your system. It contains pages to configure some of the basic dropdowns that you may use. If the dropdowns are not required then the options can be left blank. The lists that are created can be added to at a later date if required. Any thing that is not on the forms will be discussed with you Implementation Consultant on your setup days. Below is an explanation of each page of the spreadsheet.
Once the system has been created you will be contacted by your Implementation Consultant to discuss moving forward. The implementation days are used to look at your organisation in details and set the system up accordingly. You will be shown every step that is required and run through the options available. This is an important step to getting set up and running and the full process will be planned by your designated consultant.
Before the system can be used there are some steps that need to be taken. In this section you will find guidance to what needs to be set up in relation to the core settings of the system.
It is worth familiarising yourself with the group access security and checking that the system administrators group has full access to the system. Before starting ensure that the System Administrator group has full access to all areas of the system. For further details see Group Access.
System details allow you to enter your organisation details with a section to add a message for users as they log in.
This is an important section that is not to be overlooked as it contains the overall security settings for accessing the system. Some of the other items may not seem relevant in the early days and you may find that you will revisit this area at a later stage.
Review the 3rd party software if you wish to use any of the optional systems. If you wish to use the email options within the system it is highly recommended that you use your organisations own email server. You may experience issues if you use our servers depending on the setup of your domain. If you have Spoofing Protection enabled most recipients will reject the email and send a message failure notification back to the system. If you do not have Spoofing Protection enabled most recipients will accept the email with a high chance of marking it as Junk Mail/Spam. When you use our system the email is sent on your behalf, using your specified email address, this method is now known as spoofing.
Think about which record types you require, from Clients through to the organisations that you work with. With each of the record types you also need to think about which fields to include on these records. To customise the records see Customise Orgs & People.
Once you have chosen which fields are going to be used you can the setup these fields.
Services are setup as projects in the system. One service may require one or more projects based around reporting requirements. You may also wish to consider have enquiry projects separate to the service provided. When it comes to reporting the enquiries will be reported separately to the projects that offer a set service.
Example
The next step is to determine the security groups that you need for your users. See Group Access for further details (Not available on Local, Members and Single Project systems). Once you have configured your required groups you can the setup the users and put them in the groups and specify which projects they work in. See Users for full details.
Users
From the fields that you have setup you may find that you require additional fields. These fields can be added to the tabs that you have configured or at the base of the record. The extension databases can be restricted by the Group Access groups setup. For further details see Extension Database Setup.
