>

DARS Overview of Roles, Responsibilities and Data Access Protocols

From DARSwiki
Jump to: navigation, search



Preface

This article will be updated on a regular basis. Updates may be required in response to updates to DARS or changes to business processes or errors.

Refer to DARSWiki Conventions for information on icons and other conventions that may apply to this User Policy Document.

Ensure you are familiar with the Data Protection laws before adding data to records in DARS. Refer to DARSWiki FurtherHelp for further information and relevant links.

Please think twice before printing this article. If a printed copy is necessary, ensure it is printed double-sided and always recycle old versions.

Last Modified: 07 October 2012


Introduction

This document explains the DARS data access protocol and the roles and responsibilities inherent in the System, which went live on 3 September 2009. DARS currently comprises Blackbaud’s CRM, Direct Marketing and Internet Solutions software, customised to Oxford’s needs.

For further details, contact the Head of DARS.


Who is DARS for?

The purpose of the Development & Alumni Relations System is to provide a common source of data on all alumni, donors and friends, as well as shared support resources, shared knowledge, advanced functionality, and common and consistent processes. These benefits, together with an online portal and email forwarding service designed specifically for alumni, are delivered within one integrated System for development and alumni relations professionals across the collegiate University.


DARS may be used by colleges, faculties, departments, administrative units, international offices, recognised alumni societies, and sports and other University entities (known as Participants). It comprises data that have been collated by the University and each of the Participants.


As a shared resource, DARS supports a collaborative approach to fundraising and a more tailored interaction with our constituents. Significant benefits can be achieved from this coordinated and joint approach, including keeping details more up to date, enhancing the quality of our communication at all levels, and developing a better mutual understanding of our relationship with alumni and supporters.

Governing Principles

By signing up to DARS, Participants are confirming that they will work within the boundaries established by the principles outlined in the following three University documents:


  • Principles and Protocols for Fundraising for the collegiate University
  • Relationship Management and Major Potential Donor scheme for the collegiate University
  • Clearance System: Guidelines for Good Practice


Underpinned by these principles, DARS has been configured to restrict information according to three different tiers; the shared tier accessible by all Participants, the restricted tier accessible by qualifying Participants (including the Relationship Manager) and the secure tier accessible only by users within a specific Participant. Additionally, each user is assigned a role which grants them access to certain types of data and which may restrict access to other areas of the System. For example, only Revenue Administrators will be provided with access to bank account details.

Key Concepts

The following four statuses are especially important within DARS and are used in a number of functional areas and processes throughout the System.

Relationship Manager

Each constituent will have a Relationship Manager (RM) security group assigned to it. The RM is the collegiate University entity with the primary relationship to the constituent. For alumni and students, it is the responsibility of colleges between them to identify the appropriate RM; usually it will be a constituent’s first college, unless and until another college has been identified as having the primary relationship with the constituent. Other individuals, companies, trusts and foundations will usually have the Central University (the University as a whole including all of its departments) assigned as RM, unless it is determined that their primary relationship with the collegiate University is with a college.i


RMs manage requests by other fundraisers to approach their constituents (within the boundaries of the University’s agreed Clearance Procedures). RMs must also act as the primary data reviewers for their constituents within DARS, with responsibility for reviewing all of the shared and restricted data that is stored on DARS for these constituents. In instances of dispute in relation to the primacy, accuracy or appropriateness of data, the RM will have the authority to make the final decision.


Where it is established that another Participant has the primary relationship with a constituent the RM (and associated Prospect Manager) may be reassigned at any time, for example where an alumnus’ primary relationship is not with their first college, but with their second (or any other) college. Upon confirmation by both parties of this reassignment, the current RM or System Administrator will make the necessary changes to the constituent’s record.


In this way, DARS facilitates building up a comprehensive register of Relationship Managers to the collegiate University’s alumni, donors and friends.

Prospect Manager

Where a college is RM, the default contact for Clearance or any other requests will usually be the Head of Development for that college; the Head of Development may, however, delegate the responsibility to another suitably qualified person within their team. Where the Central University is RM the default contact for Clearance or any other requests will be the UO Relationship Lead. In DARS, this primary contact individual in either scenario is formalised on any constituent Prospect’s record as the Prospect Manager (PM).


The PM is therefore always a member of the RM to that constituent. He or she is responsible for co-ordinating relationships and approaches that different fundraisers across the collegiate University may have with that Prospect and must be notified (via a Step in the Prospect Plan) of any planned approach by another fundraiser; he or she will then approve or reject this suggested approach giving due regard to all relevant circumstances.

Interested Parties

Each constituent will have one or more Interested Party (IP) Sites assigned to it. An IP is, broadly speaking, a Participant who can demonstrate a substantive existing relationship with the constituent. The RM is automatically assigned as an IP to the constituent.ii


Users within these IP Sites (or their parent Site) can view certain restricted data for the constituent, including donation information, wealth screening data, interactions, attachments and notepads. For alumni constituents only, any IP colleges are also permitted to make approaches below £25,000 without first seeking Clearance from the RM.iii


Pre-defined rules determine whether a Site qualifies as an IP and may therefore be added by an overnight System process to that constituent's record. It is a necessary pre-condition of this status that the relevant data to determine such qualification is entered into the correct field(s) on DARS. Additionally, the RM to a constituent may choose to add one or more IPs to the constituent’s record, if it considers it appropriate to do so. See Interested Parties Qualification Rules.iv

UO Relationship Lead

If a constituent is a Prospect then s/he may also have a UO Relationship Lead (RL) assigned to their record. Always a fundraiser within the University Development Office or another fundraising department, the RL is the primary contact within the Central University for that constituent. The RL must be notified (via a Step in the Prospect Plan) of any planned approach by another Central University fundraiser; s/he will then approve or reject this suggested approach giving due regard to all relevant circumstances. Where the Central University is RM to a constituent, the RL is also the PM. RL status does not grant additional access to data, nor does it supersede the RM’s authority.v


Data Protection

We hope that alumni, donors, students, staff and friends will all benefit from interactions with those undertaking development and alumni relations activity across the collegiate University but it is very important to ensure that their personal data are held and used appropriately.


To ensure compliance with the Data Protection Act 1998 and other legislation such as the Privacy and Electronic Communications (EC Directive) Regulations 2003, all colleges, faculties, departments, administrative units, and University international Development offices who wish to use DARS are required to enter into a standard form Participation Agreement or Memorandum of Understanding, which sets out various requirements on all Participants in relation to use of DARS, including compliance with the detailed obligations set out in the DARS Rules for Participation.


It is crucial to compliance with the DPA that individuals are aware of the holding and usage of their personal data in any system and do not object to it. For DARS Participants, this is respected by provision of the DARS Data Protection Statement which gives the individual information relating to the permitted purpose and other relevant information about the processing of personal data in DARS, and by the individual’s rights to opt out of their data being held at any time.


There is also a responsibility to check, so far as is reasonably possible, that the details held are up to date and that clear principles are followed both in terms of the recording of data and the subsequent usage of that data for communication purposes. For the purposes of the DPA, the University and the applicable Participant(s) are joint “data controllers” of the personal data held.


Departmental Alumni Databases and Spreadsheets

The University has made a significant investment in creating and developing DARS to ensure that it is a System which drives an increase in the fundraising performance of the collegiate University; facilitates stronger lifetime relationships; and advances Oxford as one of the best HE institutions in the world in terms of the return-on-investment, effectiveness and professionalism of its collegiate-wide development and alumni relations activities.


As above, underpinning these goals are recognised benefits to sharing data and working collaboratively with that data; utilising advanced functionality (offline and online) within a modern developed System; de-duplicating data entry and standardising list values; consistent adherence of DPA requirements; and sharing resources such as training, support, and infrastructure. Alumni, too, benefit from collaborative approaches, interactions tailored to the individual’s wishes, and ‘one-stop’ updating of information.


It is thus strongly recommended that Departments and Centres of the University should not create or maintain their own separate fundraising or alumni relations databases (including those held on spreadsheets). Having invested in DARS, it is important to the collegiate University that those categories of entities which would best operate within this System and accompanying framework – and who will commit to working within the requirements set out – should use DARS rather than an alternative database or spreadsheet.


Requirements of New Participants

For any new entity (Department/College/Centre etc) to join DARS, the following requirements must be met:

  1. The DARS Participation Agreement / Memorandum of Understanding must be signed by the entity.
  2. Users must agree to adhere to the Participation Agreement and Rules for Participation, which include abiding by the Principles and Protocols, the Clearance Good Practice Guidelines and the University’s Data Protection statement.
  3. Users must agree not to share access to the System with colleagues who are not assigned users.
  4. The entity must be engaged in or intending to engage in active alumni relations and/or fundraising activity.
  5. Those individuals who are nominated for access to DARS must have alumni relations and/or fundraising as a defined part of their job and must be an employee rather than a volunteer.
  6. Those individuals who are nominated for access to DARS must sign an Individual User Agreement and undertake all the necessary pre-access training, and commit to familiarising themselves with any updates to the system.
  7. Of those individuals from each new entity, a single lead person must be identified with whom the DARS Support Centre will liaise concerning compliance.
  8. All users must maintain records of constituent interaction (prospect plans, communications history, events, appeals, gift management, etc) to an appropriate standard as set out in the pre-access training and Rules for Participation.
  9. There will be a regular review by the DARS Support Centre to ensure users are complying with these standards.
  10. For departments and centres only, a manager within UODO or UOAO will take responsibility for monitoring and co-ordinating the new entity’s use of DARS. This is not a reporting line – however, the member of staff responsible for development and/or alumni relations in the entity will be responsible to this person for the appropriate use of DARS.
  11. Issues of inappropriate usage of DARS and maintenance of standards (as deemed by the manager in UODO/UOAO or by the DARS Support Centre) will be referred to the Pro-Vice-Chancellor (Development & External Relations) or to DARS System Management Committee for resolution as appropriate.
  12. There is an Annual Service Charge to the entity (or to a sponsor such as UODO, UOAO or a College or PPH if agreed separately), based on the number of concurrent users required.
  13. The DARS Programme Board also retains the right to charge a joining fee to cover the costs of migration and to determine the timing of that migration.
  14. The DARS Programme Board also retains the right to grant or deny access to any new entity.


System Security

DARS is constructed using a mix of functionality and data access controls to ensure security of data within the System. In particular, each user belongs to a Site within the collegiate University Site hierarchy that determines the data and some of the functionality they can access. Users are also assigned System roles based on their job that further restrict the functionality they can use and what types of data they can read or write. Together, the Site Security and the User Role Security held by each user control the access they will have within DARS.


Site Security

Each Site’s data permissions will determine the access of its users to data and functionality (in tandem with User Roles). There are three tiers of data about constituents within the System (n.b. System Administrators can access all data in the System):

  • Shared Site data: contains e.g. name, address, email, telephone number, date of birth, education history (including pre- and post- Oxford education), interests, clubs and societies the constituent is/was a member of, bursaries, scholarships, prizes, honours, qualifications etc received by the constituent, mailing preferences and the mailings or other bulk communications a constituent receives, events the constituent has attended, a donor band, family details and information on children, spouses and other family members, notepads written about the constituent, summaries of Prospect Plans with the constituent, and details of the RM, IPs, PM, RL, Constituent Data Reviewer, etc.


  • Restricted Site data: contains further constituent information available only to certain Sites, with different levels of restriction depending on the data in question:
  • IPs and Central University for e.g. interactions; documentation notes, media links and attachments; and wealth information
  • IPs and Collegiate Services role for e.g. donation information
  • IPs only for e.g. bank account information
  • Specific Sites only for e.g. Prospect Plan details including Opportunities, which are limited to a single Site by default, but can have additional Sites added when appropriate


  • Secure Site data: contains secure or anonymous records that must be kept confidential to the specific Site that inputs the record. The whole record of a constituent, specific interactions or specific gifts can be given a ‘Secure Site’ code; the information will then only be available to that Site. Such records can even be limited to just specific users within their Site, by using the ‘Strictly Anonymous Site’ code (within each Site only a subset of users receive this).


Site Security may reasonably be amended from time to time, subject to DARS System Management Committee approval.

User Role Security

Participants may have several users who need to perform different tasks within DARS. For security, users’ access is restricted based on their job role, via the assignment of System roles, each of which permit different view, edit or functionality access; thereby ensuring users can only do those tasks necessary to fulfil their role.


A user can be assigned multiple System roles, but all users must complete any requisite DARS training courses before System access is granted. User roles (and the associated training courses) may reasonably be created, amended or removed from time to time, subject to DARS System Management Committee approval. User roles currently available fall into three categories:


  1. Standard roles
    • Constituent Manager role: Users with this role can create and edit e.g. name and contact details; education details; interests and involvements; communications; attributes; interactions; documentation notes, media links and attachments; volunteers; and can carry out relevant searches. Training pre-requisite: Fundamentals 1 course.

    • Enhanced Data Manager role: Users with this role can access Queries, export and some reports, and can view event attendances on the constituent record. Training pre-requisite: Fundamentals 1 and Fundamentals 2 courses.

    • Events Manager role: Users with this role can access the Events functionality to create and edit events and enter associated event data. This includes adding event payments and event reports. Training pre-requisite: Fundamentals 1, Fundamentals 2 and Events Management courses.

    • Development Professional role: Users with this role can access the Prospect and Fundraising functionality and can create and edit Prospect, Appeal and Wealth data. The Principles and Protocols for Fundraising governs any fundraising activities. They can also view donation information for constituents where their Site is an IP including limited write access in revenue, e.g. to edit designation codes, and they can view the Designation Hierarchy and Fundraising reports. Training pre-requisite: Fundamentals 1, Fundamentals 2 and Fundraising courses.

    • Collegiate Services role: Development Professional users within the Research, Proposals, Gift Registry, Donor Relations, Campaign Co-ordination and DARS Support Centre teams of the University Development Office, which provide services across the collegiate University development community, may be granted this extra role with read-only access to donation information at a collegiate University level (excluding Secure Site revenue).

    • Revenue Admin role(s): Slightly different roles exist depending on the Participant. Training pre-requisite: Fundamentals 1, Fundamentals 2 and Revenue Administration courses:
    • College/Department Revenue Manager: Users with this role can access Revenue functionality to create and edit pledges, payments and recurring gifts with a designation code applicable to their Site; to create or edit campaigns, appeals, designations and purposes; to write off pledges; to clear matching gift claims; and to map/post revenue to the General Ledger for their Site. This includes access to Gift Aid declarations and bank account details. They can also view Prospect information, including limited write access in their Site’s Prospect Plans, e.g. to edit Opportunities, and Revenue reports. Where a gift is made to the University for transfer to their Site, the processing will be completed in collaboration with the Central Revenue Administrator.
    • Central Revenue Admin: Users with this role can access Revenue functionality and can create and edit pledges, payments and recurring gifts with a designation code applicable to the Central University. This includes access to Gift Aid declarations and bank account details. They can also view Prospect information, including limited write access in University Prospect Plans, e.g. to edit Opportunities, and Revenue reports. Where a gift is made to the University for transfer to a college or department, the processing will be completed in collaboration with the appropriate College/Department Revenue Manager.
    • Central Revenue Supervisor: Central Revenue Admin users within the UODO Gift Registry team may be granted this extra role, which provides additional access and functionality in Revenue, Fundraising and Appeals to create or edit campaigns, appeals, designations and purposes; to write off pledges; to clear matching gift claims; and to map/post revenue to the General Ledger for the Central University.

    • Marketing and Communications Manager role: Users with this role can access the Blackbaud Direct Marketing (BBDM) functionality to create and edit Appeals and Marketing Efforts and enter associated marketing data and responses. This includes access to several reports. Training pre-requisite: Fundamentals 1, Fundamentals 2 and Marketing & Communications courses.

    • Web Editor role(s): Users with one or more of these roles can access the Blackbaud Internet Solutions (BBIS) functionality to create and edit webpages. Training pre-requisite: Internet Solutions Essentials course and an existing BBIS website (or site currently in progress).


  2. Administrator roles:
    • System Administrator role: This role is limited to approved individuals within IT Services, Blackbaud and the DARS Support Centre. Sys Admin have access to and can amend (including delete) all parts of the System, including all Secure Site data, as required to carry out System configuration, maintenance, weekly checks, fulfilment of Subject Access Requests by data subjects, monitoring/audit and reports; and to advise and assist operational users (including ‘Run As’ functionality to simulate access of the user). Training pre-requisite: All existing courses plus specialist Blackbaud/IT Services/DARS Support Centre training.

    • Local Site Administrator role: Certain “Super Users” may be granted this additional role, which provides some functionality access to configure specific areas of DARS to reflect the needs of their Site. This includes additional delete abilities, batch import and notifications. The Head of Development for each Participant together with the Head of DARS determine the user(s) within their team responsible for carrying out this task. Training pre-requisite: All existing courses plus specialist IT Services/DARS Support Centre training.

    • Constituent Data Reviewer role: Users may be granted this additional role, which provides Data Review functionality for constituents assigned to their RM, in order to review (and if necessary roll-back) address changes. The Head of Development for each Participant determines the user(s) within their team responsible for carrying out this task. Training pre-requisite: Fundamentals 1 and Fundamentals 2 courses plus specialist IT Services/DARS Support Centre training.


  3. Read-only roles, which may be stand-alone or added to standard roles:
    • Management Executives role(s): To facilitate their senior status within the collegiate University, some senior management users (e.g. Chancellor, Vice Chancellor, Registrar, Pro-Vice Chancellors, Heads of College / Division / Faculties / Departments, Estates Bursars) may be provided customised roles with read-only access to most shared data and to restricted data for those constituents where their Site is an IP. Their role may additionally include access to Queries, export and some reports. Training pre-requisite: Specialist IT Services/DARS Support Centre training.

    • College Officer role: Users with this role have read-only access to a subset of the DARS data, but only for those constituents for whom their Site is an IP. They will not be able to view any data for other constituents. This is to facilitate the College provision of services to alumni and other constituents within their Site. Training pre-requisite: Read-only course.

    • College Lodge Porter role: Users with this role have read-only access to a very limited subset of the DARS data e.g. contact details and event registrations and some education details, but only for those constituents for whom their Site is an IP. They will not be able to view any data for other constituents. This is to facilitate the College provision of services to alumni and other constituents within their Site. Training pre-requisite: Read-only course.


Categories of System Use

The System may be used only for the “permitted purposes” stated in the Data Protection Statement, as posted on the DARS Website and the Alumni website at www.alumni.ox.ac.uk/data_protection. Broadly speaking, the permitted purposes fall into the following four categories:


Fundraising

The purpose of fundraising is to generate income for the collegiate University through gifts from its alumni and friends, and from companies, trusts and foundations. There are different methods of fundraising and types of approach, and these and the level of collaboration will depend on the relationship with the constituent and other IPs. There are three broad categories of fundraising:


  • Major Gifts: typically defined as gifts or pledges (ordinarily for a period of five years or less) to one or several parts of the collegiate University totalling £25,000 or more including Gift Aid. The RM is responsible for co-ordinating approaches to the constituent for a major gift: if a Participant other than the RM wishes to make an approach, they must seek formal Clearance. Such Clearance will be managed through Steps within Prospect Plans (the constituent must be flagged as a Prospect) and any resulting consent is specific to the recorded Plan only. If the RM grants consent, each subsequent step leading to and including any solicitation should be tracked through the Prospect Plan.

  • Legacies and Planned Gifts: A planned gift is typically defined as a gift expected at a future time that has been outlined by a donor and provided for in his or her estate plan. A legacy (bequest) through a donor’s will is the most common type of planned gift; others include Charitable Bargain Sale, Retained Life Estate, Pooled Income Fund, Charitable Remainder Unitrust, FLIP Unitrust, Charitable Remainder Annuity Trust and Charitable Lead Trust. Assets donated can include cash, appreciated securities, real estate, life insurance, retirement plans, self-invested personal pension plans (SIPPs), personal property, business interests and partnership interests.BREAK For alumni only, any IP colleges are permitted to make Legacy/Planned Gift approaches if unspecified (or specified below £25,000) without first seeking Clearance from the RM. The RM is responsible for co-ordinating all other (targeted) approaches to constituents for a Legacy/Planned Gift: if a Participant other than the RM wishes to make an approach to a constituent, they must seek formal Clearance. Such Clearance will be managed through Steps within Prospect Plans (the constituent must be flagged as a Prospect) and any resulting consent is specific to the recorded Plan only. If the RM grants consent, each subsequent step leading to and including any solicitation should be tracked through the Prospect Plan.

  • Annual Fund Gifts: typically defined as gifts or pledges (for a period of five years or less) totalling less than £25,000 including Gift Aid. These are often obtained through appeals that involve structured communications activity throughout the year including solicitations by letter, email, telephone calls, web and face-to-face meetings. For most low-level giving, an individual Prospect Plan is not necessary for each donor; Annual Fund approaches are instead tracked through the Appeals and Marketing Efforts functionality of DARS. In certain situations however, for example when making a face-to-face request, it may be desirable to establish an individual Prospect Plan (the constituent must then be flagged as a Prospect).BREAK For alumni only, any IP colleges are permitted to make Annual Fund approaches without first seeking Clearance from the RM. Under specific conditions agreed by the Pro-Vice-Chancellor in advance, departments may also be permitted to make Annual Fund approaches to those alumni with whom they have an education history, employer and/or donor relationship.BREAK The RM is responsible for co-ordinating all other (targeted) approaches to constituents for an Annual Fund gift: if a Participant other than the RM wishes to make an approach to a constituent, they must seek formal Clearance. Such Clearance will either be managed through Steps within Prospect Plans (as with Major Gifts) or, for bulk appeals, through separate correspondence with the RM in which case the requestor should seek written consent from the RM to make an appeal to an agreed set of constituents before proceeding.


Further details about fundraising in DARS can be found in the appropriate sections of the Fundamentals 1, Fundamentals 2, Fundraising, Revenue Administration and Marketing & Communications training manuals.

Alumni and Donor Relations

The purpose of alumni and donor relations is to strengthen lifetime relationships with alumni, donors and other constituents who have a connection to the collegiate University. This especially involves alumni, but is also relevant to spouses, students, current and former staff, parents, and other donors and friends who have a pre-existing relationship or membership to the University or one or more colleges. Activities include alumni and donor events; publications, e-bulletins and other communications; donor stewardship; regional, interest-based and professional alumni networks; careers support; personal information updates; alumni/donor benefits and entitlements. Where such activity extends beyond alumni and donor relations, for example into fundraising, the consent of the RM must be sought.


The University Alumni Office, Development Office, Events Office and Publications & Web Office (each based within University Administration and Services, or UAS) may conduct alumni and donor relations’ activity with any alumni, subject to Data Protection obligations, any Clearance rules that apply, constituents’ Solicit Codes and Mail Preferences, and a rule of reasonability.


Any Participant may conduct alumni and donor relations’ activity with those constituents for whom it is an IP, subject to Data Protection obligations, any Clearance rules that apply, constituents’ Solicit Codes and Mail Preferences, and a rule of reasonability.


Any Participant may conduct alumni and donor relations’ activity with those constituents where it can be clearly demonstrated that that constituent is/was a member of the department, centre, club or society that is responsible for the communication, subject to Data Protection obligations, any Clearance rules that apply, constituents’ Solicit Codes and Mail Preferences, and a rule of reasonability. In instances of doubt, the Participant must seek permission from the RM before contacting the constituent.


Any Participant may conduct alumni and donor relations’ activity with a constituent if it can be clearly demonstrated that that constituent has opted in or expressed an interest to receive or join that specific communication, network or group, subject to Data Protection obligations, any Clearance rules that apply, constituents’ Solicit Codes and Mail Preferences, and a rule of reasonability. In instances of doubt, the Participant must seek permission from the RM before contacting the constituent.


In all other instances, Participants must not conduct any unsolicited communication (whether by post, email, text or fax message, or telephone call) to any constituent or group of constituents without receiving permission to do so in advance from the RM or the constituent. “Unsolicited” in this instance means any communication that has not been preceded by a (relatable) communication from that constituent. This is necessary to minimise the risk that a constituent may unwontedly receive contact.


Further information about alumni and donor relations in DARS can be found in the appropriate sections of the Fundamentals 1, Fundamentals 2, Event Manager, Fundraising and Marketing & Communications training manuals.vi

Other Types of Event Management

As well as the events mentioned above, DARS may also be used to organise events or conferences that are not directly related to fundraising or alumni and donor relations, e.g. events and programmes involving academic or administrative departments, student events, external conferences, and business forum events. This data may be helpful to share in instances where there is a crossover of information, interests or relationships, e.g. a company attending a business forum event may also be a donor to the collegiate University. However, only Participants using DARS for development and alumni relations will be permitted access to the System for this additional function. Furthermore, constituents’ involvement for other types of events must be by their opted-in consent only or with the permission of the RM.

Further information about events in DARS can be found in the appropriate sections of the Fundamentals 1, Fundamentals 2 and Event Manager training manuals.


Other Types of Marketing and Relationship Management

DARS may also be used for marketing and (customer) relationship management that is not directly related to fundraising or alumni and donor relations, e.g. merchandising, associate/membership programmes, further education courses, visitor links, and student management. This data may be helpful to share in cases where there is a crossover of information, interests or relationships, e.g. a person registering for a short-course programme may also be an alumnus of the collegiate University. However, only Participants using DARS for development and alumni relations will be permitted access to the System for this additional function, and there are restrictions on the types of data, particularly relating to students, which may be stored. Furthermore, constituents’ involvement must be by their opt-in consent only or with the permission of the RM.


Further information about CRM can be found in the appropriate sections of the Fundamentals 1, Fundamentals 2, Revenue Administration and Marketing & Communications training manuals.

Contact Responsibilities

Subject to Data Protection obligations, contact with constituents by Participants should be recorded on DARS, unless the constituent has requested otherwise. Where reasonably possible, these instances of contact should be recorded as:

  • Communications: used for bulk correspondence sent to multiple constituents at the same time, whether by mail or email (or possibly in the future by text message);
    • Appeals – those communications related to Fundraising and/or which occur across a specific time period and have a monetary goal
    • Event Invitations – those communications related to Events
  • Interactions: used for individual or personalised contact with constituents, whether by mail, email, telephone call, text or fax message, or in person.vii


In all cases, such contact must abide by the:

  • DARS Data Protection Statement that the constituent has been notified of and had an opportunity to respond to;
  • The Rules for Participation and any other guidance which may be provided from time to time;
  • Clearance and other contact rules for the different categories of System use that may apply;
  • Requests made by that constituent with respect to receiving contact;
  • Internal decisions made by the RM or the user’s Site for that constituent with respect to making contact.


Contact Requests

Any contact requests should be stored within Solicit Codes or Mail Preferences as appropriate. Whenever either of these is created or edited, an explanation should be provided in the Comments field of that Solicit Code or Mailing Preference, so that other Participants/users will understand the reason for the contact block/request. If an end date to a Solicit Code is added at any stage as a result of a subsequent request (by the same requestor), then an explanation for doing so should be added to the Comments field of that Solicit Code or Mailing Preference.


Any requests made by a constituent – whether in person, by telephone call or via another form of Interaction – with respect to altering Solicit Codes or Mail Preferences for a particular Site should be dealt with by that Site directly. If a user receives a request pertaining to a Participant other than his or her own, then the constituent should be redirected to contact the affected Participant (providing their contact details where needed). Wherever reasonably possible, a user should not update Solicit Codes or Mail Preferences for another Site.


Any requests made by a constituent – whether in person, by telephone call or via another form of Interaction – with respect to altering Solicit Codes for all Sites should be dealt with by the RM or by the DARS Support Centre. If a user receives such a request and his or her Participant is not the RM for that constituent, then s/he should re-direct the constituent to contact either the RM or DARS Support Centre (providing their contact details where needed). Wherever reasonably possible, only the RM or DARS Support Centre should update Solicit Codes that pertain to all Sites.


For further details, see DARS Solicit Codes and Mail Preferences.

Monitoring Changes

Users must only make those amendments to a constituent’s data that are necessary for the fulfilment of their role or necessary for ensuring that the information is correct and up to date. In all other instances, a user must contact the RM before making changes. RMs, IPs and System Administrators should regularly monitor and review all data changes. System Administrators are able to view and query on the audit list of changes to a constituent through their Constituent History including the date of the change, the type of action, and the user who made it.

It is possible for the RM to view and, if appropriate, ‘roll back’ changes to contact details if they are deemed to be incorrect, via the Constituent Data Review report. All other data changes can be altered by manually re-inputting the original information, which as above is stored in audit tables. In instances of doubt over the primacy, appropriateness or accuracy of shared information, the relevant parties should consult to determine the correct data, with the RM reserving the right to make the final decision. Additionally, System Administrators reserve the right to remove immediately from the System any data that conflicts with Data Protection obligations; however, where possible, s/he will seek to do so in consultation with the RM and/or Site-owner of the data.


i The DARS Support Centre can provide each college with a list of those alumni for which it is an IP but is not currently listed as the RM; the college can then choose to discuss these assignments with the relevant other colleges if and as deemed necessary.


ii The current Site Hierarchy within DARS, as may be amended from time to time, is available on the DARS Website.


iii The University Development Office (and its various teams), Alumni Office and Events Office, and other University departments and administrative units, all collectively come under the ‘Central University’ parent Site. In some instances, Site and User Role Security is equivalent across this parent Site and its child Sites; in other instances, access is restricted according to the specific Site (parent or child) in question; and in yet other instances, access from one child Site is rolled up to the parent Site of Central University but not across to other child Sites. However, they all share the same Secure Site called ‘Central University Secure’.


iv The IP qualifying rules, as may be amended from time to time, are available on the DARS Website.


v For an alumnus or other college prospect, internal RL clearance must take place before any external clearance request is submitted to the college RM.


vi Donor Stewardship in DARS is covered as part of the Fundraising Training course.


vii Interactions can also be linked to Appeals (through Marketing Efforts) and/or Events.

Personal tools
Namespaces
  • Page
  • Discussion
  • Variants
    Actions
    Navigation
    DARS User Support
    DARS Support Centre
    Advancing Oxford
    Tools