Revision as of 15:24, 6 July 2018

NEW ADMIN GUIDE

This section is being re-written, the old guide is further down the page.

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

Pre-Implementation Spreadsheet (not used for 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.

Introduction

The Introduction sheet give you details on how to complete the forms.

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.

Ethnic Groups

Ethnic groups are generally use for reporting outputs. Populate a list based on what your organisation requires across all services.

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.

Religions

If your organisations requires to support or report on religious groups then enter the name of each group you need.

Sexual Orientation

In addition to the gender field on the system there is the option to record a persons sexual orientation.

Districts/Wards

On the records is the option to place people/organisation into reporting areas. This list is to populate those areas.

Disabilities

This is used for specifying a persons disability/ailment and can be used in reporting. An individual can have multiple.

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.

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.

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.

Living arrangements

This is for how a person live at the accommodation,; lives alone, with partner, with parents, multiple occupancy cell.

Referral Sources

Referral sources are 'How did you here about us' include things like Advert, website, web search etc.

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.

Termination Reasons

Termination reason are used when removing a service user from a project, specifying why a service is lo longer required.

Referral Outcomes

These simple outcomes are case closure outcome like case closed successful claim.

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.

Benefits

You can add benefits and amounts if you assist your service uses in this area.

Gender

Enter the genders that you work with, think about adding categories for gender re-assignment.

Contact Types

Contact types are used to distinguish direct and indirect done for a service user.

Main Language

Used to specify the main spoken language of your service users.

OLD ADMIN GUIDE

1. Throughout the build of the system, you will be able to control how it goes together, ensuring your organisation's needs are met
2. You will be able to change and adapt the system in the future for your changing needs
3. When changes are required, this can be done by your staff, for free - instead of having to pay for software development

Of course having every user of the system able to change the setup would be a very bad idea - chaos would reign! We recommend that if you're a customer organisation, you nominate a few people (usually between 2 and 6) to be your in-house administrators.

I'm an administrator... what do I do?

You'll be setting up the system with help from your Implementation Consultant. Some administrators might oversee the whole system - others might just have ownership of the part of the organisation they work in. Often, service managers administrate their own services, which means they can make sure that the data they need for reporting/performance monitoring is captured.

Then, once your system is up and running, the Administrators - you - will be left in charge. Of course we're not trying to pass all the responsibility of running the system onto you - there is support available:

• Help bubbles within the system tell you what certain features do
• Every page in Charitylog has a linked section in this manual
• The technical support line

File:Qsadmin chart1.png

As you can see, part of the administration team's ongoing work is to help the end users with the system. When you first implement Charitylog, there will probably be a few questions, but over time the end users will become familiar with the system and are likely to be able to find the help content they need in the manual.

Internal Support Users

Optionally, anybody can be set as an Internal Support User. There is a drop-down field on the user record for each person to say whether they are an Internal Support User or not:

File:Qsadmin 1.png

If set to "Yes", this person will appear on a help screen if a user fails to log in properly. They will be shown a screen like this:

File:Qsadmin 2.png

Note that they are shown the email address and phone number listed in the user's record, so although the system may tell you that such an entry is invalid, it can be useful to enter an internal extension (as shown) so that the user knows who to call if they need help logging in.

File:Qsadmin 3.png

Setting up and running the system

You might see the system during the sales/tender process, or you might not have seen it until implementation day 1. Either is fine! The aim of this first day is for you to get a good grasp of the Charitylog system, so that you can think about the ways that it will work for you. Day 1 also provides an opportunity for your Charitylog Implementation Consultant to get to know your organisation well.

Day 1

On day 1 you will be shown the basic system, and taught how to:

• Log in
• Search for clients (and other types of Organisations or People) and create new ones
• Record contacts with them
• View the history of contacts that has happened with them
• See your outstanding work on the Action List

Depending on your organisation, and the pace of the day, you may well cover more material too.

After day 1

After day 1 your Implementation Consultant will leave you with some tasks to complete before the next day of implementation. These are likely to include setting up some Projects, and amending Drop-Down Lists.

What follows day 1 will depend on the needs of your organisation, and will be decided by your Implementation Consultant.

Helping users log in to test databases

As well as your live system, your organisation will have access to at least one "test" database - a replica of your live system for training and experimenting. This can be updated to mirror the current state of your live system at any time - click here for details: Update Replica Databases.

Users may need help logging into these systems, as the first pair of usernames and passwords are different to the ones that they usually use.

Once logged, page backgrounds will have the word "TEST" displayed to alert users as to which database they are logged into.

File:Qsadmin 4.png

If you are using an Alpha or Beta version of the system, this will also be displayed on the background.

File:Qsadmin 5.png

Rob Kay - manual author (talk) 09:13, 19 January 2016 (GMT)