-
-
-## Key concepts
-
-### Open data
-360Giving data is open data, which is defined as follows:
-
- > Open means anyone can freely access, use, modify, and share for any purpose (subject, at most, to requirements that preserve provenance and openness).
-
-For further information visit the Open Definition website.
-
-### 360Giving data
-360Giving data is the term we use to describe any grant information shared in the 360Giving Data Standard. 360Giving data can be viewed in files published by a wide range of funders or explored in online tools built by 360Giving and others.
-
-### Publishers and publishing
-Organisations that share 360Giving data are the owners of the information and when they make the files of data available online as open data, it is called **publishing the data**. That is why we call the funders that share 360Giving data **Publishers**.
-
-### JSON
-The 360Giving Data Standard is defined by a JSON Schema, which describes the structure and attributes of the information can be shared. JSON, which stands for **JavaScript Object Notation**, is a data interchange format commonly used for transmitting data in web applications.
-
-For further information visit the JSON schema website.
-
-### What's next?
-Read our guidance about planning your process and deciding what data to share.
diff --git a/documentation/guidance/cf-guidance.md b/documentation/guidance/cf-guidance.md
deleted file mode 100644
index cf40d162..00000000
--- a/documentation/guidance/cf-guidance.md
+++ /dev/null
@@ -1,214 +0,0 @@
-# Guide for Community Foundations
-
-Want to know who publishes, and why?
-Visit the 360Giving website to read about the benefits of publishing and see who’s involved in publishing
-
-
-## Overview
-In collaboration with UKCF, 360Giving has supported the development of a tool for the Digits2 (D2) system which means that grant information can be extracted from your system ready-formatted to the 360Giving Data Standard.
-
-Community foundations participating in a pilot were consulted to agree a field specification for the 360Giving data file and a data extract tool was developed for use by any community foundation that wishes to share open grants data.
-
-This tool built into the D2 system means that the technical aspects of preparing your data will be automated, making the process easier and quicker. There are some additional practical steps you need to follow when sharing your 360Giving data for the first time, for example the hosting and licensing of the data.
-
-Below there is specific step-by-step guidance for community foundations using the D2 tool, and links to other relevant guidance found on this site. You can also download this guidance [PDF 384kb].
-
-Watch the video walk-through
-
-## The information included in the D2 extract
-The D2 360Giving data extract tool allows you to publish useful information about the grants you have awarded.
-
-The range of information fields included in the extract file is fixed, however you can control the content of your data by using report filters, for example to decide what time period or grant programmes will be included.
-
-See the guidance on [deciding the scope of your data](decide-what-grants-to-include) for further details.
-
-### What to consider if you make grants to individuals
-The D2 360Giving extract tool automatically anonymises the names of individuals who have received grant awards. The beneficiary location for individual grant awards is shared at local District or Ward level.
-
-The D2 extract anonymises the names of individuals, however extra care should be taken to check other fields in the grant data, such as **Title**, **Description** and **Recipient Org:Description**, as well as Beneficiary fields, to ensure that this information, on its own or when combined, cannot be used to identify the individual concerned.
-
-If you take further steps to anonymise or remove potentially identifying data make a note of the changes you make, and ensure these checks and steps are taken each time you publish new data.
-
-See the guidance on [data protection](../../guidance/data-protection/) to consider the implications for your organisation of sharing open grants data.
-
-### Anonymising donor names in programme titles.
-If programme titles include the names of donors the D2 360Giving extract has been developed to allow the names to be redacted. There is further guidance below about [how to set programme names as ‘undisclosed’.](undisclosed-programme)
-
-## Contact 360Giving to get access to D2 extract
-Each community foundation must be set up with access to the 360Giving reports folder in order to generate the source report and extract 360Giving data.
-
-If you cannot find the 360Giving report folder in your D2 system, please contact 360Giving Helpdesk via Not using the Digits2 grants management system?
-This guidance is for community foundations using the Digits2 grants management system on Salesforce only. If you do not use Digits2 use the side menu to go to guidance on preparing your data.
-
-
-
-
-
-
-It is possible to restrict access to the D2 tool to certain individuals in your organisation, or it can be made accessible to all users with a login. If you want to restrict access you will be asked for the names and emails of the people who are allowed to use the tool, so these permissions can be added to the system.
-
-### Walk-through video
-Watch the video walk-through to get an overview of the process and follow the instructions below to export 360Giving data from your D2 system.
-
-## The source report
-A dedicated report folder is created for each community foundation containing the template report that is used as the source for the data extract. This report can be used to check data quality and to apply the correct filter criteria to limit the grant applications that are included.
-
-
-
-Navigate to the **Reports** tab:
-- Locate the folder that is prefixed with your Community Foundation name and followed by ‘360Giving Reports’ (enter 360 in the folder search box to find this folder)
-- Click on the folder to display the template report
-- Click on the report name to open the report
-
-The report template contains all the fields that are sourced directly from the grant application and the associated applicant account records that are included in the agreed 360Giving field specification.
-
-The default filter shown below is set to include all grant applications that have a Record Type of ‘General Approved’ and an amount greater than zero.
-
-You can change the DATE filter to control the grant applications that you would like to include in the extract. Use this report to check the information that will be published and edit it in the source fields if required – particularly text fields such as **Project description – summary** and **Purpose of Organisation** and **Project name**.
-
-
-
-#### Note:
-- **DO NOT remove** the Grant Application ID (circled above) from the report OR move it from the first column – this must remain where it is for the extract process to work
-- If you drag additional fields in to the report, they will NOT be included in the grant extract file but can be included for checking purposes
-- Individual grant recipient names will appear in the report, but these will default to ‘Individual recipient’ in the extract file if they are a Person Account instead of an organization.
-- If project name is blank, then the output will default to ‘Grant to org name’ – if it is person account this will output ‘Individual recipient’
-
-The following system-generated fixed or calculated values will not appear in the report but will be included in the extract file:
-
-
-| 360Giving field | -Notes | - - -
|---|---|
| Funding Org:Name | -This is your organisation name as you want it to appear in your data. This could be your brand name rather than your full registered name. | - -
| Funding Org:Identifier | -This is created based on your registered charity or company number. | - -
| Publisher prefix | -This is used to register your organisation with 360Giving and provides a prefix for grant identifiers. | - -
-
-
-
-
-
-```eval_rst
-.. _undisclosed-programme:
-```
-
-### Undisclosed programme
-If you do not want to publish the name of specific Programmes, there are 2 new fields in the 360 Giving section on a programme record. Tick the 360Giving – Display as undisclosed checkbox and the 360Giving – Programme Title will default to Undisclosed. This is the value that will show in the programme name on the data extract.
-
-
-
-### Generating the file
-To generate the formatted extract file in .xls format, go to the new tab called **Export Grants Data to 360 Giving**.
-
-This can be added to the tabs across the top menu bar (by accessing customise my tabs via + symbol) or just by locating it in the list of **All tabs** displayed when you click on the + symbol on the right of the menu bar.
-
-
-
-You will see your Community Foundation’s summary identifier information displayed at the top.
-
-Click on the **Import grants from a report** dropdown and the report template that is stored in the dedicated folder will be displayed.
-
-
-
-Click on the report and the following message will appear:
-
-
-
-The total number of rows in the report will display.
-
-
-
-Click on the **Export Excel** button to generate the extract file.
-
-**Note:** the file may take longer to open if there are a large number of records in the file so you may need to be patient.
-
-Open the excel file to review data.
-
-Save the file to your local drive as an .xlsx file. To do this click on ‘Save file as’ and **choose Excel Workbook with the .xlsx file extension**.
-
-## Check data quality and receive feedback
-Once you have exported a file of your data using the 360Giving extract, the next step is to check that the data is valid. Valid data means the file includes all the required fields and the information has the correct formatting.
-
-Each Community Foundation is responsible for the data it publishes. You can check that your data is valid using this Data Quality Tool developed, which will tell you if there are any issues with your dataset.
-
-See the guidance on [checking data quality](../../guidance/data-quality/) before publishing your data.
-
-## Publishing your 360Giving data
-Once you are happy with your data file and the Data Quality tool shows that the data is valid, the next step is to find a place on your website for hosting the file and outlining the open license you are releasing it under.
-
-All organisations publishing data to the 360Giving Standard host their files on their own website, which means they have control over and are responsible for their data.
-
-See the guidance on [publishing your data openly](../../guidance/publish-data-openly/) for further details.
diff --git a/documentation/guidance/data-protection.md b/documentation/guidance/data-protection.md
deleted file mode 100644
index 9f40844f..00000000
--- a/documentation/guidance/data-protection.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# Data protection
-
-| 360Giving field | -Salesforce source | -Notes | - - -
|---|---|---|
| Identifier | -Grant Application Reference Number | -The grant identifier will be the unique Grant Application reference number prefixed with each Community Foundation’s unique organization identifier e.g. 360G-CF-XXXXXXX | - -
| FundingOrg:Identifier | -Static value for each CF held on CF Profile record | -This is a unique identifier for each Community Foundation made up of a prefix and their charity number. Eg GB-CHC-1151621 | - -
| FundingOrg:Name | -Static value for each CF held on CF Profile record | -Name of Community Foundation | - -
| Planned Dates: Duration (months) | -Default Value | -To be calculated based on start and end dates | - -
| Beneficiary Location: Country Code | -Default Value | -Default to GB | - -
| Beneficiary Location:Geographic Code Type | -Default Value | -The data extract supports all geography levels Super output area, Ward, Local authority, Westminster Parliamentary or Constituency. | - -
| Currency | -Default Value | -Default to GBP | - -
| Last modified | -Default Value | -This is the date on which the data was last updated and will be populated automatically | - -
-
-
-Key tasks
--
-
- Check your privacy policies and grant agreements. -
- Check whether your 360Giving data could include personal data. -
- Consider the responsible data implications of sharing data. -
- Remove or anonymise personal data or get informed consent to share it. -
- Decide whether to notify your grantees about your 360Giving data. -
-
-
-## Overview
-The data collected by funders about the awards made to grantees belongs to the funder, and information about organisations and the grants they receive is not personal data. However, grants to individuals, grants to smaller organisations, or named contact details for organisations, may contain or constitute personal data.
-
-In general, **open data should not contain personal or sensitive personal data that could allow a living person to be identified**. Data to be published using the 360Giving Data Standard which does relate to identified individuals should be removed or anonymised to protect their privacy.
-
-Although there are circumstances where publishing personal data is in the public interest, in the case of 360Giving data, personal data should only be included with the consent of the individual concerned.
-
-The guidance below sets out what to consider when publishing your grant data openly for the first time, and notifying your grantees about your 360Giving data.
-
-## Checking privacy policies and grant agreements
-If your organisation already announces details of grants through annual reports, web pages or press releases, you should already have processes in place that establish your rights to share this information publicly.
-
-- Check the terms of your grant agreements for any existing clauses relating to publicity and disclosure of information about grants.
-- Check if your organisation has a privacy policy, or terms and conditions that applicants agree to when submitting grant applications.
-
-### Reviewing your policies
-When reviewing your grant agreement or terms and conditions:
-
-Include:
-- An explicit statement that public information might be shared in open datasets.
-- A clear statement of scope (state whether you will release just summary information, or you will release detailed grant information, including payments and results).
-- If applicable, a clear statement of any personally identifying information you plan to publish (e.g. names, addresses), and details of how grantees should opt-in, or opt-out of which data being shared.
-
-Avoid:
-- Statements that imply published information will only be used by specific partner organisations (as this restriction cannot be placed on openly licensed data).
-
-### Public vs personal information
-Attention should be paid to any data you intend to publish which may be personally identifying under the Data Protection Act 2018, including:
-- Grants to named individuals.
-- The contact person, and their contact details, at an organisation you have funded.
-- Personal/residential addresses, for example when an organisation is registered at a home address.
-
-If you intend to publish information about individuals that could be personally identifying, you should either:
-1. Make sure you have explicit opt-in consent to publish this within an open dataset.
-2. Or remove or anonymise the information in line with the Information Commissioner's anonymisation code of practice.
-
-## If you do not intend to publish personal data
-In general, information about organisations and the grants they have received can be published as open 360Giving data without concern.
-
-However you should still check for personal data appearing by accident. For example descriptive text may include the names or contact details of individuals involved in a project or organisation.
-- Check **Title**, **Description** and **Recipient Org:Description** fields, as well as recipient or beneficiary location data, to ensure that this information, on its own or when combined, cannot be used to identify the individual concerned.
-- Pay particular attention to any text fields where the source information is entered by applicants via an online application form, especially if the text does not get checked and edited during the grant assessment process.
-
-If you need to take further steps to anonymise or remove potentially identifying data, make a note of the changes you make to ensure these checks and steps are taken each time you publish new data.
-
-### Organisations registered at a home address
-If the address of an organisation is a private home address, which can be the case for grassroots or informal groups and small registered charities, this information is not suitable for inclusion in 360Giving data in full.
-
-Redacting street-level addresses, and including only the postal town and the postcode may be sufficient to prevent the information from identifying an individual. However the appropriate approach to redaction will depend on the context of the data, for example by only including the first digits of the postcode if the address is in a sparsely populated rural area.
-
-Some publishers avoid the possibility of publishing home address data by sharing recipient location data using geocodes instead of address information.
-
-This option has been used by funders who frequently fund smaller or informal groups where there is a high likelihood of home addresses appearing in their data. This approach also suits funders who award large volumes of grants where distinguishing which recipients use home addresses would be challenging or time-consuming.
-
-For further information see our [guidance about how to convert postcodes into geocodes.](converting-postcodes-into-geocodes-to-anonymise-address-information)
-
-## Responsible data
-There can be cases where grant data is sensitive for reasons other than privacy. For example, the address of a women’s refuge might be inappropriate to include in data about a grant to that organisation.
-
-Consider whether any of your grant data might contain other sensitive information, and make sure you have a process in place to review and redact it (or seek consent to publish) where required.
-
-**Sharing Data Responsibly – A Conversation Guide for Funders** is designed for funders and grantmakers who want practical advice on how to treat their grantees’ data responsibly. Published by the Ariadne Network and Engine Room, this report is aimed at Human Rights funders working internationally, but has relevant information for all other types of funders.
-
-Access the Responsible Data guide.
-
-The guide follows the grant management cycle, providing information to guide decisions at each stage:
-- **Data collecting**: managing data in the application, monitoring and reporting phases.
-- **Storing grantee data**: how to provide clear information on which data is collected and why, and how you will store it.
-- **Sharing and publishing information**: sharing and publishing information in a considered, responsible way.
-
-## Notifying grantees about your 360Giving data
-Even if you will not be sharing personally identifying information and so do not need to gather extra consents, you may wish to let your grantees know about your 360Giving publication, as a courtesy. This can also be a good opportunity to solicit any updates from them.
-
-If your organisation has not shared detailed information about your grants before, your communication can provide reassurance that their personal data will continue to be handled in accordance with your privacy policy, and also provide an opportunity to outline the benefits.
-
-For example, in your communication with grantees you could cover the following:
-
-**What data will be published?**
-
-The data will include the name of the grant recipient organisation, amount, date and a brief description of the purpose of the grant. (This section should be updated to reflect the fields included in your data.)
-
-**How will data be published?**
-
-The data will be available to download from our website (insert link). The data will then be available for tools that use open data, for example [GrantNav](https://grantnav.threesixtygiving.org/). This is a tool created by 360Giving, but anyone could create a tool that uses the data.
-
-**Why are you publishing data in this way?**
-
-We are proud to be associated with our partner organisations and this is a way to share information about our collective work that can support learning and better decision-making in the charitable giving sector. Publishing open data about grants awarded in this way complements the news shared about the partners’ work and achievements.
-
-For more information about the 360Giving initiative visit their website: https://www.360giving.org/
-
-## If you do intend to publish personal data
-We encourage publishers to carefully consider the value of publishing any personal information as part of their 360Giving data and discourage sharing of special category data (including racial or ethnic origin and health information).
-
-Before making a decision on including personal data:
-- Review the ICO’s Key definitions of the data protection act to understand the difference between non-personal data, personal data and sensitive personal data;
-- Review the ICO’s Guide to data protection to understand your organisation’s obligations;
-- Ensure your organisation has the power to share the data.
-
-### Start by publishing what you can
-You can still take steps toward publishing your data, even if you find that there are some data protection policy issues to address. Consider which fields and grant records are not affected by any barriers, and move forward with publishing these. The learning from this process can then be applied back to other grants once the policy issues are resolved.
-
-## Example open data policy
-An example of an open data policy is available, written by some of the experts who helped create the 360Giving Data Standard. It can be used as a template for any organisation’s data policy and adjusted to reflect specific circumstances and needs.
-
-Adopting an open data policy for your organisation will help to guide the checks you make before publishing data, and record the range and type of changes that may need to be made to your grant information before sharing it openly.
-
-### Further information about data protection
-If you want to discuss this data protection guidance and how it relates to your specific circumstances, please contact 360Giving Helpdesk via Publishing grants to individuals?
-The guidance provided below focuses on data protection considerations for funders of grants to organisations. Guidance relevant for funders intending to publish data about their grants to individuals can be found in the Guide for grants to individuals.
-
-
-## Overview
-Once you have prepared your file of grant data, the next step is to check that it is correctly formatted 360Giving data – known technically as ‘valid‘ data – using the 360Giving Data Quality tool.
-
-The term ‘valid‘ means the file includes the 10 core fields, and the information has all the correct data formatting.
-
-Only valid 360Giving data can be combined with other published data and be included in 360Giving tools, such as GrantNav and GrantVis.
-
-## How to use the 360Giving Data Quality Tool
-The Data Quality Tool (DQT) has been specially designed to support the preparation and publication of 360Giving data.
-
-You can use it by uploading a file or providing a link to a file that is hosted online.
-
-
-
-### Error message
-If you get an error message that the DQT can’t process your data, try again using a different file format.
-
-To resolve the issue, resave your data in an accepted file format and try again.
-
-The acceptable files are spreadsheets in OpenDocument Spreadsheet (.ods), Excel Workbook (.xlsx) or CSV (.csv) format or JSON built to the 360Giving JSON schema (.json).
-
-
-
-## Understanding the Data Quality Tool feedback
-
-Once you have submitted your file, the screen will display feedback on key information points about the data, divided into up six tabs depending on the results: Summary, Additional Fields, Conversion errors, Validity, Accuracy and Usefulness. Explore the individual tabs view the feedback in detail.
-
-You will see three cards which provide an initial guide to quality of data. If the data is invalid, you will see a question mark instead of a number on the Potential accuracy issues and Usefulness opportunities cards.
-
-
-
-Each tab also includes the number of issues in brackets for a quick overview.
-
-
-
-The following icons provide an initial guide to the quality of your data:
-
-- **a red exclamation mark** indicates indicates critical accuracy issues. You should check this feedback and resolve whenever possible before publishing the data.
-- **a yellow exclamation mark** indicates other checks which suggest ways to improve the accuracy or usefulness of the data.
-
-### Summary tab
-The summary tab provides basic details about the file's content – how many grants, funders, recipients, and the date range and total value of the grants broken down by currency.
-
-A green or red box at the top shows a pass or fail on validity, indicating whether the data uses the 360Giving Data Standard correctly.
-
-If any information in the summary tab is wrong, the feedback in the rest of the tool will help you investigate what is causing the issues.
-
-Even if the information in the summary tab is correct, there may be issues highlighted in the other tabs that need to be addressed.
-
-
-
-#### This file contains
-
-This section provides a basic preview of your data in a table to allow you to review the information in the tool.
-
-There is also a count of the grant, funding organisation and recipient identifiers which hyperlink to list views.
-
-**Top Tip:** If you are testing grant data for a single funder, but the summary says there is more than one unique **Funding Org:Identifier**, you can check these values in the list view.
-
-
-
-
-#### Share
-
-In this section, you can get the unique URL for the test results, which allows you to share the feedback with others. Each tab also has its own unique URL. This means you can share a link directly to a specific feedback in the Summary or Validity tab. The link will last for seven days, after which it will expire.
-
-If your data is not suitable for sharing publicly, then you should treat this URL with care. Only share it with people who have permission to access the data in its current form.
-
-#### Download
-In this section, you can download a version of your spreadsheet file converted into JSON format.
-
-If the file you have been testing is already in JSON format, you can instead select **Convert to Spreadsheet** in the Data conversion section to create an Excel spreadsheet version of the file to download.
-
-### Additional Fields tab
-This tab only appears if your data includes fields which do not use 360Giving Data Standard titles. The titles of these additional fields will be listed to help you check that they are included intentionally, and are not the result of spelling or formatting mistakes in the title.
-
-### Validity tab
-
-For data to be used in 360Giving tools and combined with other 360Giving data, it must meet the requirements of the 360Giving Data Standard.
-
-- **This data uses the 360Giving Data Standard correctly**, which means the data is valid 360Giving data.
-- **This data does not use the 360Giving Data Standard correctly**, which means issues prevented the data from being valid 360Giving data.
-
-The error descriptions include links to further information about each error. The error messages are subdivided into types of issues, with an Error Count to show how many grant records are affected by the problem.
-If there are **three or fewer grant records** with the same error, the location of the issue will appear in a preview, with the sheet name and row number for the grant.
-
-
-
-If there are **more than three grant records** with the same error, the DQT will also hyperlink to a list in the Error count.
-
-
-
-The four types of validity errors are described as follows:
-
-#### Missing fields
-These error messages are triggered if your grant records are missing data in the 10 core required fields. If your data does not include data for all 10 core required fields, the DQT will create an error for each missing field, with a count of how many grant records are missing information.
-
-Review the feedback to find where the information is missing and add relevant data to fix these issues. If there is no available data to fill in the missing fields, you may need to remove the grant record from your data until you can add the required information.
-
-**Top tip:** These errors can be triggered by a spelling or formatting mistake in the field title, which means the DQT will not recognise your data as complete. Check the ‘Additional Fields’ tab, as this will list all the non-Standard fields in your data and may help you identify the fields that need to be renamed.
-
-
-#### Incorrect Formats
-These error messages are triggered if any data formatting is incorrect, most commonly because:
-
-- A date is not in the correct format.
-- An invalid 'URI' has been found, which means there is a problem with a website address in your data.
-
-
-#### Codelist Errors
-These error messages are triggered by using codelists incorrectly. Specific fields in the 360Giving Data Standard use codelists, which means you must use one of the pre-defined codelist values when using these fields.
-
-If your data does not use the official codes, the DQT will create an error and list all the values used that are not from the codelist. The error message will link to the codelist with the expected values for the field. This issue will also trigger an error in the ‘Other validation errors’ section: Invalid code found in [field name].
-
-
-#### Other
-Other errors include text in number fields, numbers in text fields, and negative durations in the Planned Dates:Duration (months) field. The error descriptions will link to further information about each error.
-
-### Accuracy tab
-This tab highlights areas where your data may need to be corrected or need further attention. For each check, the DQT gives feedback on the issue and the steps to resolve it.
-
-Unlike the error messages in the **Summary**, **Validity** and **Conversion Errors** tabs, this feedback does not mean your data is invalid. It can be ignored when not relevant or until you can improve your data quality. However, critical feedback, marked by a red exclamation mark, should be reviewed and corrected whenever possible.
-
-The issues are grouped as follows:
-
-#### Organisations
-
-##### More than one funding organisation
-This feedback will be triggered when the file has more than one unique **Funding Org:Identifier**.
-
-While it is possible for a file to include grants awarded by more than one funder, multiple funding organisation identifiers can sometimes appear in 360Giving data by accident when the org ID is copied in Excel by dragging down the column, sequentially adding to the numbers rather than copying the same value.
-
-If you get this feedback but you are only preparing data about one funder, update the **Funding Org:Identifier** so it is consistent.
-
-##### Charity and company numbers
-If your charity or company number fields include data other than the numbers (filler text, extra numbers or letters), you will get the following error message: **XX grants have a value provided in the Recipient Org:Charity Number column that doesn’t look like a UK charity number**.
-
-If you get this feedback, you will get a similar message about your Recipient Org:Identifier data, because these are created based on the charity or company numbers in your data: **XX grants have a Funding or Recipient Organisation identifier that might not be valid**.
-
-To fix these issues, focus on cleaning the data in your system's charity or company number field, and export your 360Giving data again.
-
-##### Funding or Recipient Org:Identifier that does not draw from a recognised register
-
-Organisation identifiers in 360Giving data follow a specific format, and should either use a prefix taken from the org-id list locator or your publisher prefix which starts **360G-**
-
-This feedback highlights any organisation identifiers using unrecognised prefixes, which should be checked and updated as appropriate. See our [guidance on organisation identifiers](../technical/identifiers.md#organisation-identifier) for further help.
-
-
-#### Grants
-**Zero value grants**: If any grants have a zero **Award Amount**, the feedback will highlight these. Check if these are the result of grants being included that are not yet fully committed and remove if this is the case.
-
-#### Dates
-**Inverted start and end dates**: If you have a minus duration error, you will probably also get feedback that the start and end dates are inverted - **XX of grants have Planned Dates:Start Date entries that are after the corresponding Planned Dates:End Date**. Resolve the validity issues by correcting the dates.
-
-**Issues with dates**: If the data has an **Award Date** in the future, or planned start or end dates in the far past or far future, the feedback will highlight the affected grants. The grants published should be awarded in the past so post-dated award dates could mean the data is not suitable for publishing yet, or could be the result of errors with the dates.
-
-#### Data protection
-The tool flags text resembling email addresses, postcodes, and DEI information associated with individual recipients to highlight potential personal data, requiring review and removal, or consent before publishing to comply with the Data Protection Act.
-
-### Usefulness tab
-This tab highlights ways that your data could be made more useful. For each check, the DQT gives feedback on a key feature that makes the data useful for analysis, which we recommend including in 360Giving data whenever possible.
-
-Feedback is triggered when the following information is missing from the data.
-
-* Organisations
- * Official organisation references, such as charity or company numbers
-* Location
- * Recipient location
- * Beneficiary location
-* Grants
- * Grant programme fields
- * Grant duration
-* Metadata
- * Last Modified information
- * Data Source
-
-Unlike the error messages in the **Summary**, **Validity** and **Conversion Errors** tabs, this feedback does not mean your data is invalid. It can be ignored when not relevant or until you are in a position to update your data quality.
-
-Some of the feedback is explained in detail below:
-
-#### Organisation: grants have a Recipient Org:Identifier that starts '360G-'
-
-This feedback is common because, if an organisation doesn’t have a charity or company number or another official reference in the data, the **Recipient Org:Identifier** is created using an internal identifier instead, with the publisher prefix which starts **360G-**.
-
-If you do not collect or share charity or company numbers, or any other official organisational references, you will see this error for all your grants. It is strongly advised that you begin to collect and share this data wherever possible, as this makes it more useful and comparable.
-
-If you do collect and share charity or company numbers, or other official references, then the percentage of grants with **360G-** type **Recipient Org:Identifiers** should broadly match the proportion of grant recipients which are small and unregistered groups, or do not have official identifiers in reality.
-
-If the proportion of grants with an internal identifier is higher than you would expect, you should investigate further.
-
-If you also receive the feedback **grants do not have either a Recipient Org:Company Number or a Recipient Org:Charity Number** and there is a significant mismatch between the proportion of grants without a charity and company number and the proportion of **360G-** type org IDs, this may also point to an issue with your data.
-
-#### Location
-The usefulness feedback identifies missing recipient organisation location or beneficiary location.
-The feedback also highlights inconsistencies, such as: recipient geocodes without beneficiary geocodes, beneficiary location names without corresponding geocodes, and beneficiary geocodes without recipient organisation geocodes.
-
-
-### Conversion Errors tab
-To test data in a spreadsheet file, the DQT must first convert the data into JSON because 360Giving Data Standard uses a JSON Schema to describe the rules for the Standard in a technical way.
-
-**Please note:** This tab will not show if your file of 360Giving data is already in JSON format.
-
-- **Data conversion successful** means the DQT could convert the spreadsheet into JSON.
-- **Data conversion unsuccessful** means issues with the data prevented the data from being converted into JSON.
-
-A range of issues can prevent your data from converting successfully.
-
-**Duplicate Identifiers**
-
-All grant Identifiers must be unique, and if two grant records have the same Identifier, the DQT will try to merge the two records. If there are any differences between the two grant records, this will cause an error.
-
-To resolve this error:
-
-- If there are duplicates of the same grant in your file, delete all the duplicates until only a single record for each grant remains.
-- If the grants have duplicate identifiers, but they should be different, go back to your source information to check if the wrong identifier has been used and correct it if needed.
-- If you have related but different grants that share an identifier in your source information, you need to make these unique in your 360Giving data or merge the information into a single grant record. Add a suffix such as an extra letter or number suffix or the award date to make your grant identifiers unique. For example 360G-ExampleFnd-001A and 360G-ExampleFnd-001B
-
-**Other conversion errors**
-
-Other conversion errors are usually caused by the data not being formatted correctly. These issues are highlighted in the in the Validity tab, meaning that the conversion errors should disappear when you have resolved all the problems making the data invalid.
-
-
-### Getting more help
-Please contact the 360Giving Helpdesk via Key tasks
--
-
- Upload your prepared 360Giving data into the 360Giving Data Quality tool. -
- Review feedback and make updates if the data is invalid. -
- Check 'Accuracy' and 'Usefulness' feedback, making updates if required. -
-
-
-### About Data Quality Tool security
-The Data Quality Tool has been designed to support people preparing their 360Giving data, meaning the data inputted into it is in varying stages of readiness.
-
-The feedback report you receive has a private URL, which means only those with the link can access the page and the data. If your data is not suitable for sharing publicly, then you should treat this URL with care and only share it with people who are allowed access to the data. As long as you do not put the URL on a public page, then it will not be possible for people to come across it by accident.
-
-The files are deleted automatically from the Data Quality Tool after seven days. Read the Terms and Conditions for further details about how the files are stored and deleted.
-
-### What‘s next?
-Read our guidance about publishing your grant data openly to make it available for anyone to download and use.
diff --git a/documentation/guidance/index.md b/documentation/guidance/index.md
deleted file mode 100644
index ef64efc7..00000000
--- a/documentation/guidance/index.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Guidance for publishers
-This guide is for UK funding organisations that want to publish their grants data openly in the 360Giving Data Standard.
-
-It is designed to help you at any stage of the publishing process – whether you are at the very beginning of your journey and planning your approach, preparing your data, at the publishing stage, or starting to use the data in 360Giving tools.
-
-We want to help you achieve your goal of publishing open and comparable grants data using the 360Giving Data Standard.
-
-This isn’t a reporting process, it’s an opportunity to let people know about your grantmaking using data.
-
-```eval_rst
-.. toctree::
- :maxdepth: 3
-
- before-starting
- plan-the-process
- data-protection
- prepare-data
- data-quality
- publish-data-openly
- submit-data
- making-updates
- using-data
- cf-guidance
- location-guide
- regranting
-
-```
diff --git a/documentation/guidance/location-guide.md b/documentation/guidance/location-guide.md
deleted file mode 100644
index 8fcb1de9..00000000
--- a/documentation/guidance/location-guide.md
+++ /dev/null
@@ -1,401 +0,0 @@
-# Guide to location data
-
-## Why is location data important?
-Location data helps users to understand where organisations are based or activities are happening, which helps to build a more complete picture of where funding is going geographically.
-
-Finding out where in the UK grants go is a key question that 360Giving data can be used to answer, but this is only possible when good quality and consistent location data – also known as geodata – is shared.
-
-Location is not one of the [ten core fields](https://standard.threesixtygiving.org/en/latest/guidance/plan-the-process/#decide-what-information-to-share), so the 360Giving Data Standard does not require geodata to be included. However, location information is so useful that we do recommend including it whenever possible. When data also includes geographic codes, it makes the data more comparable, and allows the data to be visualised in maps or analysed alongside other datasets such as Indices of Multiple Deprivation.
-
-## The basics
-The 360Giving Data Standard includes a range of ways to describe locations which are split into four types of fields: recipient, funder and beneficiary location, and location scope.
-
-- **Recipient location** is where the recipient of a grant is based.
-- **Funder location** is where the funder of a grant is based.
-- **Beneficiary location** is where the funded work is being delivered or the people who access the funded work are based.
-- **Location scope** is the geographical scope of the funded work.
-
-Recipient, funder and beneficiary locations can be shared in the form of place names and geographic codes. Recipient and funder locations can also be shared in the form of an address.
-
-Location scope is shared in the form of codes from a codelist.
-
-### About geographic codes
-A geographic code, or geocode, is a unique identifier that represents a location or geographic object. These geocodes allow geographic entities to be distinguished from each other and provide a more consistent way to identify a place than using the location name.
-
-Geocodes are useful in the same way as other [identifiers](../technical/identifiers) in the 360Giving Data Standard. Whilst a person may be good at recognising that “Royal Borough of Kingston upon Thames”, “Kingston” and “London Borough of Kingston” refer to the same place, computers cannot make this connection unless a unique identifier in the form of a geocode is provided.
-
-Geocodes can be used to produce maps showing the distribution of funding geographically and allow grants data to be analysed alongside official statistics, such as the Indices of multiple deprivation.
-
-Whenever possible, geocodes should be shared by funders publishing on 360Giving with the name of the area and geocode type.
-
-**Types of geographic codes**
-
-**Country codes** - two-letter country codes taken from ISO_3166-1_alpha-2 codelist. For example the code for the United Kingdom is **GB**, the code for Spain is **ES**.
-
-**ONS codes** - nine character codes managed by the Office for National Statistics which describe a wide range of geographical areas in the UK - including the four nations of the UK, regions in England, local authority areas, electoral wards and Census output areas.
-
-**Postal Codes** - full or partial postal codes associated with a UK postal address, or the equivalent codes used in other countries.
-
-**Latitude and Longitude** - coordinates that indicate a point on the globe, using the World Geodetic System.
-
-### About Location scope codes
-Location scope codes are drawn from a codelist developed and managed by 360Giving which provides a short name, description and code for each Location scope value. These codes allow funders to share consistent information about the geographical scope relevant to each grant. For example the code GLS030 can be used to indicate that a grant is intended to have a national impact.
-
-See our [Codelist guide](../technical/codelists) for more detailed guidance on what codelists are and how they are used in the 360Giving Data Standard.
-
-## Recipient organisation location
-**Recipient location** fields indicate where the grant recipient is based. It could be the location of a main office or branch, whatever is most appropriate for the grant.
-
-Many funders collect address information from applicants during the grants management process, which makes including recipient location information straightforward. Over two-thirds of organisations sharing 360Giving data include this type of information.
-
-### Address fields
-There are fields which allow for the full postal address of an organisation to be published. However providing the city or town name and a postcode is sufficient to make the data useful.
-
-Publishing street addresses is not recommended because it does not add to the usefulness of the data and omitting these details helps to avoid privacy issues if a recipient organisation is registered at a home address or if an organisation is supporting vulnerable people (for example, a refuge).
-
-View the full range of available recipient organiation address fields.
-
-**Considering privacy**
-
-In populated areas a postcode is unlikely to identify a specific building, but in rural or less built-up areas, a postcode could be linked to a small number of addresses.
-
-When sharing data about grants awarded to individuals - or small and informal charities or groups whose address may be a home address - it is not appropriate to share any address or postcode data directly.
-
-In these cases, the location information should be converted from postcodes into geocodes prior to publishing the data.
-
-See our guidance on [converting postcodes into geocodes](converting-postcodes-into-geocodes-to-anonymise-address-information) for further information, and here is our [guidance on data protection](../guidance/data-protection/) for further considerations about privacy and location data.
-
-### Recipient location codes
-In cases when it isn’t possible or appropriate to publish postal codes, it is possible to publish recipient location in the form of Office for National Statistics (ONS) geocodes.
-
-When 360Giving data includes recipient location codes at UK **Country**, **English Region**, **Local Authority**, **Ward** or **LSOA** level, these will work with the location filtering functions of GrantNav, 360Giving’s search engine for grants data.
-
-The fields used to share recipient location geocodes should be accompanied by fields for the location name and geocode type whenever possible.
-
-Data protection
-Find out more about what to check before publishing your data openly in our data protection guidance.
-
-
-
-
-
-View the full range of available recipient location fields.
-
-## Beneficiary location
-**Beneficiary location** fields are used to describe where the funded work is being delivered or where the people who will access the service or activity are based.
-
-These fields can also be used to describe the geographical scope of a grant programme or funder’s area of operation.
-
-### Why is beneficiary location data useful?
-Including beneficiary location can provide a more accurate picture of where grants are going geographically, as these fields focus on where the impact of the funding is being directed.
-
-Beneficiary location is especially important in cases where the recipient location is in a different place from the activity being funded. This is common for grants awarded to larger regional or national organisations with head offices based in major cities that deliver services in different places around the country.
-
-**Beneficiary location names**
-
-The location names could describe any type and size of place; an estate, ward, town or city, local government area, parliamentary constituency, region or country. These values should be relevant to the scope of the grant or funded activity.
-
-Including the **location name** allows users to understand which places funding is reaching.
-
-**Using location names consistently**
-
-Ensuring location names are consistent within your own data will make the information clearer and more usable, especially if it is not possible to also publish geocodes alongside the names.
-
-For example, avoid having "Bristol, City of" and "City of Bristol" and “Bristol" or "Tyne & Wear" and "Tyne and Wear" in the same data.
-
-Also avoid using ambiguous terms such as ‘National’ which in a UK context could be interpreted as meaning any of the four nations or UK-wide. Use the specific country name - England, Scotland, Northern Ireland or Wales, or the term UK-wide to ensure users can interpret your grant data correctly.
-
-**Beneficiary location geocodes**
-
-Including geocodes that correspond with the beneficiary location names increases the usability of the data by providing a consistent way to identify these places, which make the data comparable across different funders.
-
-Data with geocodes can be used to produce maps showing the geographic distribution of funding and allow grants data to be linked with other data sources, such as official statistics. When 360Giving data includes beneficiary location codes at UK **Country**, **English Region**, **Local Authority**, **Ward** or **LSOA** level, these will work with the location filtering functions of GrantNav, 360Giving’s search engine for grants data.
-
-The fields used to share beneficiary location geocodes should be accompanied by fields for the location name and geocode type whenever possible.
-
-| Field name | -Description | -Example value | - - -
|---|---|---|
| Recipient Org:Location:Name | -A name for this location. | -Barrow-in-Furness | - -
| Recipient Org:Location:Geographic Code | -A code referring to a geographical area, drawn from an established gazetteer such as the ONS Register of Geographic Codes in the UK. For example, the code for a local authority ward, or parliamentary constituency. | -E07000027 | - -
| Recipient Org:Location:Geographic Code Type | -The type of Geographic Code (geoCode) used (e.g. Ward, Parliamentary Constituency etc.). This value for this field should be drawn from the codelist of geographic code types. | -NMD | - -
-
-
-
-
-
-View the full range of available beneficiary location fields.
-
-### Challenges with beneficiary location data
-Beneficiary location data can provide a more accurate location for the intended impact of a grant, and is therefore more useful when carrying out analysis on where grants go. However it is also a more challenging type of data to collect and publish.
-
-The types of challenges include:
-
-- This data can be difficult to collect consistently, especially if the size of areas supported by grants varies greatly from those with a national or regional scope to local or hyperlocal delivery areas.
-- A grant could fund activities in an area that crosses local authority or region boundaries or doesn’t relate to any officially defined areas.
-- The grant could fund activities being delivered in more than one place.
-- The delivery location could be undefined, for example because the grant is unrestricted, is funding policy work or services that are provided online.
-
-**Start by sharing what you can**
-
-We recommend that funders who collect location data that could be shared as beneficiary location should publish this information whenever possible.
-
-There is no one-size fits all approach to beneficiary location, as funders have a diverse range of geographical scopes and priorities.
-
-Funders with a geographical focus to their funding, especially place-based funders focused on a defined place (such as community foundations), will often be collecting detailed geodata that can be shared.
-
-Funders with national programmes or without a geographic focus might collect this location data at a high level that indicates the region or country but does not drill down to smaller areas.
-
-Currently two-thirds of organisations sharing 360Giving data include beneficiary location name information but only one-third include beneficiary location codes.
-
-### Guide to beneficiary location
-Funders have a wide range of reasons for collecting beneficiary location, and the method and level of detail will depend on what questions the data is needed to answer.
-
-These examples highlight a few of the common approaches, and outline the benefits and limitations these can have. Hopefully they will provide inspiration for funders that don’t currently collect and share beneficiary location information but would like to do so in future.
-
-**Project location postcode**
-
-Funders can ask applicants to provide a ‘project postcode’ to indicate where the funded work will take place. This postcode might relate to an address or could also be picked from within a wider area.This data can be shared directly as a postal code, or converted into a geocode prior to publication.
-
-The advantage of working with postcodes is that these are the most commonly used and understood type of geodata. A postcode can be matched to ONS geocodes and scaled up to a larger area when appropriate. Postcodes are also easy to convert into latitude and longitude coordinates for use in maps.
-
-This approach can be suitable for collecting data about very localised funding or grants aimed at a specific location, such as a building or park. It is less accurate or useful for capturing the location of grants for any activities carried out over a larger area or multiple locations.
-
-**Location picklist**
-
-On application forms funders may provide a list of locations - known as a picklist - for applicants to select the place or places where they are delivering their activities.
-
-Grants management systems might have an ‘area of operation’ field with region or country values by default. For funders with a regional or county area of focus, the list of locations might be broken down into the local authority areas or at ward level for funders focused on a single city or council area. These place names can be published in 360Giving data on their own or with their corresponding geocodes.
-
-The advantage of working with picklist values is the data is consistent and it can be straightforward to match these names with geocodes. This approach can be suitable for a wide range of funders and scaled to work for those funding nationally or locally.
-
-When location is collected at a regional or country level, the data is less usable for mapping but will still provide useful information for analysing broad trends and showing when the funded activity is in a different place from the recipient location.
-
-When multiple locations are provided for each grant it is possible to publish these in 360Giving data. See the [guidance below](multiple-locations) for further information.
-
-**Funder or programme area of operation**
-
-Funders with a defined area of operation or programmes (with place specific eligibility criteria) will know the maximum possible location area of a grant even if specific geodata isn’t being collected.
-
-This type of scope data can be applied to all grants that meet the criteria, providing a useful starting point to publishing location data. When the funder or programme scope is a local authority area, this provides useful data for geographical analysis being carried out at a county, regional or national level.
-
-However the potential for variation within council areas means data provided at this level or higher cannot be meaningfully compared with statistical data such as Indices of Multiple deprivation, which are linked to small area geographies.
-
-```eval_rst
-.. _multiple-locations:
-```
-
-### Sharing data with multiple beneficiary locations
-It is possible to include multiple beneficiary locations for each grant, because the 360Giving Data Standard allows for the creation of [one to many relationships.](one-to-many-relationships)
-
-Multiple beneficiary location fields could be used to:
-- Provide alternative types of geodata for the same location - for example including the local authority ward and parliamentary constituency area codes, and latitude and longitude coordinates which are all based on the same project postcode area.
-- Describe two or more different locations that are impacted by the funding.
-- Represent a bespoke area that does not correspond to any official ONS geocode by using a group of smaller area geocodes.
-
-For publishers using [JSON format](360giving-json-schemas), sharing data with multiple locations for each grant is straightforward as the schema is designed to work in this way.
-
-For publishers using spreadsheets, there are a couple of ways to structure one-to-many relationships for sharing multiple locations, which we have detailed below.
-
-**Including multiple location fields in the main sheet**
-
-For publishers who have three or fewer fields of beneficiary location per grant, it will be easiest to include all three within the main grants sheet.
-
-In these cases, the fields or sets of fields are numbered, starting with 0 for the first column.
-
-For example:
-
-| Field name | -Description | -Example value | - - -
|---|---|---|
| Beneficiary Location:Name | -A name for this location. | -Barrow-in-Furness | - -
| Beneficiary Location:Geographic Code | -A code referring to a geographical area, drawn from an established gazetteer such as the ONS Register of Geographic Codes in the UK. For example, the code for a local authority ward, or parliamentary constituency. | -E07000027 | - -
| Beneficiary Location:Geographic Code Type | -The type of Geographic Code (geoCode) used (e.g. Ward, Parliamentary Constituency etc.). This value for this field should be drawn from the codelist of geographic code types. | -NMD | - -
-
-
-
-
-
-**Including multiple location fields in an additional sheet**
-
-With four or more columns of location data, it may become easier to include all the beneficiary location columns in a separate sheet within the file.
-
-The main spreadsheet template includes a sheet for each part of Standard. The beneficiary location sheet includes the fields from this object and the grant Identifier, which is used to associate the data with each grant.
-
-Using this method, there should be a row for each location, repeating the grant Identifier for each group of locations associated with the grant. The following example shows two grants which each have three Beneficiary Locations:
-
-| Beneficiary Location:0:Name | -Beneficiary Location:1:Name | -Beneficiary Location:2:Name | - - -
|---|---|---|
| Copeland | -South Lakeland | -Barrow-in-Furness | - -
-
-
-
-
-
-
-```eval_rst
-.. _location-scope-guide:
-```
-
-## Location scope
-The 360Giving Data Standard allows funders to share a **Location scope** for each grant, which describes the geographical scope of the funded work.
-
-### About the codelist
-The codelist includes seven codes that should be used to describe the geographical scope of the funded work. The codes represent the different scopes a grant can have, from global to local areas. There is also a code to indicate when a grant has an undefined location, for example because the funded activity is online with no restrictions to who can access it.
-
-The location scopes were designed to align with international geographical divisions so the codelist can be applied consistently in all contexts. This means that there are areas grouped into a single scope in the codelist that have more sub-divisions in the UK.
-
-### Location scope codelist
-
-```eval_rst
-.. csv-table::
- :file: ../../codelists/locationScope.csv
- :header-rows: 1
- :widths: auto
-```
-
-### Explanation of terms
-
-#### Global
-**Code to use:** GLS010
-
-**When to use this code:**
-Grants which have a global scope, meaning the area where the funded work is being delivered or the people who access the funded work are based all around the world.
-
-#### Supranational
-**Code to use:** GLS020
-
-**When to use this code:**
-Grants which have a scope which is a supranational region or continent, for example the European Union, North America or Africa.
-
-#### National
-**Code to use:** GLS030
-
-**When to use this code:**
-Grants which have a scope which covers a country, as defined by ISO 3166, for example the United Kingdom, France or Sierra Leone.
-
-#### Subnational region
-**Code to use:** GLS040
-
-**When to use this code:**
-Grants which have a scope which covers a first-level subnational administrative area, for example English Regions, Scotland, Wales or Northern Ireland.
-
-#### Local authority
-**Code to use:** GLS050
-
-**When to use this code:**
-Grants which have a scope which covers a second-level subnational administrative area, for example Districts (England), Principal Areas (Wales), Council Areas (Scotland), Local Government Districts (Northern Ireland), Metropolitan Counties, Non-Metropolitan Counties and Unitary Authorities (England).
-
-#### Local area
-**Code to use:** GLS060
-
-**When to use this code:**
-Grants which have a scope which covers a small area below local authority level, for example a Ward, MSOA, LSOA, parish, town, village, estate or park.
-
-#### Undefined
-**Code to use:** GLS099
-
-**When to use this code:**
-Grants which have a scope which is undefined, where location is not relevant, for example for online activities with no geographical focus.
-
-### Deciding which code to use
-The code descriptions and guidance provide examples of which codes to use to categorise grants’ location scope, focused on the UK context. If the grant you want to categorise could fit into more than one scope - for example the grant is funding a local pilot and UK-wide awareness raising campaign - label using the broadest applicable scope GLS030 (National).
-
-If the grant is funding activity in multiple different areas which are within a single scope – for example funding a project operating in two or more English Regions or activities which are England-wide – the location scope would be GLS040 (Subnational region).
-
-If you are not sure which category is appropriate for your grant, contact | Identifier | -Beneficiary Location:Name | -Beneficiary Location:Geographic Code | - - -
|---|---|---|
| 360G-ExampleFdn-001 | -Copeland | -E07000029 | -
| 360G-ExampleFdn-001 | -South Lakeland | -E07000031 | - -
| 360G-ExampleFdn-001 | -Barrow-in-Furness | -E07000027 | - -
| 360G-ExampleFdn-002 | -Carlisle | -E07000028 | - -
| 360G-ExampleFdn-002 | -Allerdale | -E07000026 | - -
| 360G-ExampleFdn-002 | -Eden | -E07000030 | - -
-
-
-## Overview
-Many organisations choose to update their data annually, some publish every six months or quarterly, with others doing an update following each grant award round. The aim is to have timely information available - but what 'timely' means will be different for different organisations, depending on circumstances and how often grants are awarded.
-
-Making an update to your 360Giving data will normally follow the same process as publishing data for the first time, but it should be quicker the second time around.
-
-## Document your publishing process
-It is a good idea to write down your internal process for publishing your 360Giving grants data. This will make it easier when you need to make updates to your data, particularly if you intend to update on an annual basis as it can be easy to forget the process when done infrequently.
-
-These notes will also be valuable if someone takes over responsibility for preparing and publishing your 360Giving data.
-
-You may want to make a note of:
-- The range of data you are publishing, and where it can be found in your systems or files.
-- The practical steps you take to transform the data into 360Giving format - are you exporting data directly from your system, using a conversion tool or another method.
-- Any data protection or responsible data checks and changes that need to be made before the data is ready for publishing.
-- Who is involved in checking or signing off the data.
-- Where your 360Giving files are hosted, and who is responsible for adding files to your website or hosting platform.
-
-## How often should you update your data?
-Minimum good practice is to update data on an annual basis.
-
-The decision about how frequently to make updates is for each publishing organisation to decide and should be informed by your grantmaking cycles and capacity.
-
-Once you have completed the 360Giving publication process for the first time, you will have a better understanding of the amount of time and resources needed. This will help you work out how to fit updating your 360Giving data alongside your other grantmaking and publicity cycles.
-
-## How to make updates to your data
-When you have more grant data to publish you will follow the same steps you used to prepare your first batch of data.
-
-The process to make an update of your data might involve running the same report from the earlier grant data but increasing the latest grant date to cover the current period. This report would include information about grants you've already published and newer grants and will reflect any changes that have been made since you last published your data.
-
-This process is only possible if you do not make changes to your data to get it ready for publication, so that the information in your system matches what is in your 360Giving data file.
-
-If you make changes to your data after exporting it from your system - for example changing description text to make it suitable for publishing openly – then you will need to produce a report to cover only the recently awarded grants and then incorporate the data into the existing file.
-
-Once the data is ready and it has passed the [Data Quality Tool](../../guidance/data-quality) checks you can either:
-- Add the new grant data into the existing file of published data and re-upload the file to your website. If you can keep the file name and the position of the file the same following an update it will mean the link from the Data Registry to your data will stay the same – so your updates will automatically get picked up in our system.
-- Upload a new file alongside your existing file, add a link to the file from your hosting page and let the 360Giving Helpdesk know about the new file.
-
-### Letting 360Giving know about updates to your data
-If you publish a new file of data, or if your existing data file has been updated and the location or name of your data file has changed, you need to submit the changes to the Data Registry using the [360Giving data file submission form](../guidance/submit-data.md).
-
-Remember to remove any old files from your website when making updates.
-
-If your 360Giving data file has a generic name and it is uploaded to a consistent place in your website then any subsequent updates you make to the file will get picked up by the Data Registry automatically because the link to your file will be unchanged. If your 360Giving data file has a consistent link it will not be necessary for you to fill out the 360Giving data submission form each time you make an update.
-
-Read our guidance on [good practice in file management](../guidance/publish-data-openly.md#good-practice-in-file-management) for further information about making your file link consistent.
-
-## Making changes to your published data
-You can make changes to your data at any time. This may be to add new grants data or amend details or to fix typos. It might also be to remove grants that were awarded but didn’t go ahead, or to amend grants that have been varied in some way.
-
-For further guidance about making changes to your data to note variations to your grants, see our blog post.
-
-Making amendments to your 360Giving data can be done manually, by taking a copy of your published data file and making the necessary changes. You then save the file and re-upload it to your website, replacing the current file.
-
-### Grantee amendments
-Recipients of grants published in 360Giving data have a mechanism to report issues related to inaccurate or misleading information about their organisations; such as the recipient name or recipient identifiers, description text or location. The mechanism also allows recipients to request the removal of information considered personal or sensitive.
-
-If a recipient organisation raises a valid issue about data you have published using the **Grantee Amendment** form, the details will be passed on to your organisation by 360Giving.
-
-Publishing organisations are not required to make changes to their 360Giving data following a recipient request, unless there is a data protection infringement. However sharing high-quality and accurate information benefits both funders and recipients by reducing the risk of the information being misunderstood or misused. It is expected that requests to remove personal or sensitive information should be actioned promptly, and in these cases, 360Giving will follow our existing Take Down Policy.
-
-Find out more about the grantee amendments mechanism.
-
-### Changing how your name appears in 360Giving tools
-The name of the funding organisation that appears on GrantNav and 360Insights is mostly derived from the 360Giving data that is published. This means that to update how your name appears you need to update the text in the Funding Org:Name column in your data, and then re-publish the file(s).
-
-The name that appears on the 360Giving Data Registry, and the organisation page for each publisher in GrantNav, is controlled by 360Giving. For any queries about the process to change the name in your data, and to request an amendment to the 360Giving Data Registry please contact the 360Giving Helpdesk via Key tasks
--
-
- Make a note of your publishing processes as a reminder for next time. -
- Decide how frequently to make updates to your 360Giving data. -
- Submit any new or updated files of 360Giving data to the Registry. -
-
-
-## How long the process takes
-The amount of time it takes to prepare and share 360Giving data can vary depending on your circumstances. The key factors that can determine how long the process will take are:
-- The type of grants management system used
-- The amount of data to be published
-- Whether the data is well-organised and consistent
-- If key data is poor quality or missing
-
-It will normally be possible to estimate the work involved once you have decided on the scope of your data.
-
-## Decide what information to share
-The full 360Giving Data Standard is comprehensive, with over 100 fields available to describe information about grants, recipients and funding organisations, programmes, locations and more.
-
-There are **10 core fields** of information which all 360Giving data must include. These fields ensure that the data will be usable and describe the **who, what, when and how much** of each grant.
-
-### 10 core fields
-360Giving Data Standard can be used to publish data about grants awarded to **organisations** or **individuals**.
-
-Eight of the 10 core fields are consistent for all types of grantmaking:
-- Identifier
-- Title
-- Description
-- Currency
-- Amount Awarded
-- Award Date
-- Funding Org:Name
-- Funding Org:Identifier
-
-The remaining two required fields are different depending on whether the recipient of the grant is an organisation or an individual.
-
-If the recipient is an organisation:
-- Recipient Org:Identifier
-- Recipient Org:Name
-
-If the recipient is an individual:
-- Recipient Ind:Identifier
-- Recipient Ind:Name
-
-Key tasks
--
-
- Decide what information to publish – the scope of the fields, what time period your data will cover and whether you will be sharing data about all of your grants. -
- Check if there are any Data Protection and Privacy considerations, and review your policies to ensure you can share your data responsibly -
-
-
-#### Grants to individuals and data protection
-
-The fields are titled **Recipient Ind:Identifier** and **Recipient Ind:Name**, however the data shared about individual recipients is expected to be anonymous, with no personal data included that could allow the recipient to be identified.
-
-#### Recommended fields
-Apart from the 10 core fields, all other fields are optional. However the majority of publishers do share a range of further information which make the data more useful and help users to understand their grantmaking better.
-
-If the **recipient is an organisation**, the following types of information are commonly shared.
-- Charity and company numbers
-- Recipient location
-- Beneficiary location
-- Grant duration and/or planned start and end dates
-- Grant programme details
-- Metadata
-
-You can be pragmatic when making these choices. If you have this recommended information available, then consider including it.
-
-If you don’t collect certain data or the information is not relevant to your grantmaking, these fields can be left out of your 360Giving data. For example not all funders have programmes, and location information may not be relevant to grants awarded for policy or research.
-
-It is possible to start by publishing simpler information and then extend the range of fields you include over time.
-
-#### Further information about core and recommended fields
-You can view and download further details about the core, recommended and optional fields for **funders of grants to organisations** in the Notes about the 360Giving Data Standard (link opens in Google Sheets).
-
-For further information about **Recipient location**, **Beneficiary location** and **Location scope** fields visit the [360Giving guide to location data.](../guidance/location-guide)
-
-You can find further information about the core and recommended fields and codelists for sharing information about **grants to individuals** in our [Field guidance.](../individuals/publisher-guidance.md#field-guidance)
-
-For further information about all the possible fields in the 360Giving Data Standard, visit the [Technical Reference section.](../technical/reference)
-
-#### Additional fields
-If you have information that doesn’t fit any of the 360Giving Data Standard fields provided, you can include these in additional fields.
-
-A file of 360Giving data can include any number of these **non-Standard** fields, however you will need to take care with the titles and make sure the data formatting is consistent.
-
-For guidance on naming your own fields, visit the [Additional fields section.](additional-fields)
-
-```eval_rst
-.. _decide-what-grants-to-include:
-```
-
-## Decide what grants to include
-360Giving is a voluntary initiative and you can decide what information to share in your open grants data, based on what is appropriate to your circumstances.
-
-The majority of 360Giving publishers data about all their grants, but there are examples of those who share data about certain programmes, or only grants over a certain value.
-
-If your goal is to publish data about all your grants but you find there are practical or policy issues to address first, work out which grant programmes or grants are unaffected by these barriers, and move forward with publishing these. The learning from this process can then be applied to other areas of your grantmaking once the issues are resolved.
-
-### Decide whether to share historical grant data
-You can publish data going as far back as you want (and have data for) or focus on sharing information about recent grants.
-
-Some funders have published many years of historical data, while others have started by sharing data about the past year or recent grant award rounds. The decision about how much historical data to share is often informed by practical considerations.
-
-These questions will help you to decide.
-- How accurate and complete is the data in your systems?
-
-If there are gaps or inaccuracies in your older data, then start from a point where you are confident in the quality of the information.
-
-- Is your past grantmaking similar to your current funding priorities?
-
-If your historical grant awards are not representative of what you fund now, you may prefer to start from the beginning of your most recent grantmaking strategy.
-
-The more grant data you can share, the greater the benefit to users of 360Giving data. However, if you start by publishing recent grants, you can decide to include more historical data at a future point.
-
-Hint
-Seven of the 10 core fields are commonly collected as part of the grantmaking process, and may be stored in a grants management system. Three pieces of information are usually added as part of the data preparation process: Funder name; Funder identifier and Currency
-
-
-## Taking inspiration from others
-You may find it helpful to look at the data published by other funders to understand how it works in practice and help you to picture how your own grants would appear.
-
-#### Data Quality Dashboard
-The Data Quality Dashboard shows the data quality of 360Giving data as a whole and for each individual publisher. It provides insights into the key features that make the data useful for analysis to help publishers to identify opportunities for their data to be improved.
-
-Data protection
-Once you have decided the scope of the information you want to share, it is important to carefully consider if there are any privacy or data protection implications to publishing your grant data.
The data protection requirements and steps that need to be taken to ensure grants data can be shared responsibility are different for funders of grants to individuals than they are for funders of grants to organisations.
Read our guidance on data protection for funders of grants to organisations or funders of grants to individuals.
-
-#### GrantNav
-GrantNav is our search engine for grants data. Explore and download data about where funding goes and how much is given across billions of pounds of grants, for causes and locations across the UK.
-
-Each GrantNav grant record has its own page with the 10 core fields showing at the top with other fields that have been shared displayed in a table below.
-
-
-
-As well as looking at a single grant record view, you can view lists:
-- Grants awarded to a particular organisation
-- Grants to recipients located in a particular place
-
-You can also search the data by keyword. For example, this search shows grants awarded with the term ‘village hall’ in the grant title or description.
-
-You can filter your results by grant size, date, location, grant programme, funder, funder type and recipient. You can also download the results of any searches or open the results for searches with under 10,000 grants in 360Insights.
-
-
-
-For more guidance about how to explore 360Giving data in GrantNav visit the GrantNav Help site.
-
-#### GrantVis
-GrantVis is a tool to help you understand funders better. You can combine and visualise 360Giving and charity data, and explore funders across different areas – from their grant dates to types of recipients.
-
-You can filter the GrantVis dashboard to see results for grants based on grant programme, organisation type, size or region.
-
-
-
-### What's next?
-Read our guidance about data protection aimed at funders of grants to organisations and what to consider when publishing open grants data for the first time.
-
-
-
diff --git a/documentation/guidance/prepare-data.md b/documentation/guidance/prepare-data.md
deleted file mode 100644
index c3c23e91..00000000
--- a/documentation/guidance/prepare-data.md
+++ /dev/null
@@ -1,237 +0,0 @@
-# Prepare and format your data
-
-
-
-### Overview
-By the end of this stage you will have prepared your grant data ready for publishing, and have tested that the file is formatted correctly in the 360Giving Data Quality tool.
-
-How you prepare your data will be influenced by how you collect and store information about your grants.
-
-For many publishers, preparing their data is a manual process that involves exporting information from a grants management system and converting it in a spreadsheet file. However, some grants management systems make it possible to build in some or all of the steps needed to convert the information, so it can be exported directly from the system in 360Giving data format.
-
-## Register with 360Giving Helpdesk
-If you are publishing your grants data for the first time please fill in our Publisher Registration Form to let us know more about your organisation, so 360Giving Helpdesk can provide tailored support to suit your needs.
-
-You will be provided with a **360Giving Publisher prefix**, which identifies your organisation and will be used in your 360Giving data to provide a unique identifier for each grant. For further information see our guidance about [grant identifiers.](grant-identifier)
-
-## Choosing your file format
-There are two file formats available for publishing 360Giving data, spreadsheets and JSON.
-
-### Spreadsheet format
-Spreadsheets are the most common way for publishers to share their data – the majority of 360Giving data files are spreadsheets. Acceptable file formats are CSV (.csv), Excel Workbook (.xlsx) or Open Document (.ods). Is it not possible to publish in older Excel file formats (.xls).
-
-You do not need specialist technical knowledge or specialist software to use spreadsheet file formats to publish.
-
-### JSON format
-JSON format is used for exporting the data directly from a grants management system or database, using the 360Giving JSON schemas. Some specialist technical knowledge is needed to use JSON to publish 360Giving data.
-
-Check the [technical refence on JSON schema](360giving-json-schemas) for further details and look at examples of JSON files available via the 360Giving Data Registry.
-
-**Please note:** using JSON format involves publishing the data in a JSON file; it is not an API.
-
-If you decide to use the JSON file format to publish your data you will likely need support from a developer to set this up. Contact the 360Giving Helpdesk via Key tasks
--
-
- Register with 360Giving Helpdesk. -
- Decide whether to publish using spreadsheet or JSON file format. -
- Choose a data preparation method, informed by your grants data management systems. -
- Decide whether to publish Metadata about your 360Giving data. -
- Check that your prepared data passes the 360Giving Data Quality Tool checks. -
-
-
-## Overview
-At the beginning of this stage you should have a file of 'valid' 360Giving data that has passed the 360Giving Data Quality tool checks and is technically ready to be published. By the end of this stage you will have published your grant data as open data, making it available for anyone to download and use.
-
-Prior to publishing your data, you should also check the contents of your data to ensure it is accurate, and that there is no personal data included that could allow an individual to be identified. For further information, read our guidance on data protection for [funders of grants to individuals](../individuals/publisher-guidance.md#data-protection) and [funders of grants to organisations](../guidance/data-protection.md).
-
-## How to make your 360Giving data open
-Data published to the 360Giving Data Standard is open data, which means the information is available to everyone to use and share for any purpose. For further information visit the Open Definition website.
-
-### Choose an open license
-While there are several choices for open data licenses, we recommend a license that does not restrict use but does acknowledge you, the publisher.
-
-To this end, our default recommendation is the Creative Commons Attribution 4.0 International (CC BY 4.0). With this license, anyone can share or adapt your data for any purpose, even commercially. The only restrictions are that they must give appropriate credit, provide a link to the license, and note any changes made.
-
-Find out more about the CC BY 4.0 license.
-
-#### Open license for the public sector
-If you are a UK public sector organisation, you should use the Open Government License. This is the UK government’s open data license which public sector bodies are encouraged to use by the Re-use of Public Sector Information Regulations 2015 (RPSI).
-
-Find out more about the Open Government License 3.0.
-
-#### Why 360Giving data is openly licensed
-Without a license, data is not open data and potential users would not know what they are allowed to do with it.
-
-Providing your 360Giving data under an open license is a straightforward way to let users know that they have permission to use the data, as well as any conditions of use.
-
-- The licenses are free to use so there is no charge associated with openly licensing your 360Giving data.
-- To use an open license you include the details of the license you are using alongside the link to your 360Giving data file, as shown in the example open license statement.
-
-#### Example open license statement
-Here’s an example of a license statement based on our recommended CC BY 4.0 license. Simply replace the words in square brackets with information about your organisation and grants.
-
-> **[Organisation]** is committed to transparency and we work with 360Giving to publish information about our grants.
-> Using the 360Giving Data Standard, our awarded grants since **[Year]** are available as **[File Type]** here.
-> This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. This means the data is freely accessible to anyone to be used and shared as they wish. The data must be attributed to **[Organisation]**.
-
-> We believe that with better information, funders can be more effective and strategic decision makers. 360Giving supports funders to publish open data about their grants, and empowers people to use this data to improve charitable giving through a range of free online tools. For more information, visit https://www.360giving.org
-
-## How to host your 360Giving data
-The final step is to prepare a place online where your 360Giving data file will be available for download. For most 360Giving publishers this means hosting the data on their website but there are also some [alternative hosting methods](alternative-hosting-options) that can be used.
-
-### Hosting your 360Giving data on your website
-It is best practise for organisations publishing data to the 360Giving Data Standard to host their files on their own website. This means they have control over, and are responsible for, their own data.
-
-You can host the data file anywhere on your site and place a link to it where it can be easily found.
-- You could create a dedicated “open grants” section/page on your website.
-- You could link to your data file from an existing page which shares information about your grants awarded, or alongside your annual report.
-- Or you can choose another place which makes sense for your website’s structure.
-
-#### Using the 360Giving logo
-If you would like to use the 360Giving logo on your website, there is a special design that publishers can use.
-
-Please do not use the main 360Giving logo without permission.
-
-Key tasks
--
-
- Decide what open license to use. -
- Select a location online to host your data. -
- Publish your 360Giving data file alongside the details of the open license. -
- Let 360Giving know about your file so it can be added to the 360Giving Data Registry. -
-
-#### Example hosting pages
-Here are some examples of what other 360Giving publishers have done.
-
-Linking 360Giving from an existing webpage:
-- Community Foundation for Surrey
-- Somerset Community Foundation
-- John Lyon’s Charity
-- Virgin Money Foundation
-
-Linking 360Giving data from a dedicated open data page:
-- Andrew Lloyd Webber Foundation
-- BBC Children in Need
-- City Bridge Foundation
-- The National Lottery Heritage Fund
-- Julia Rausing Trust
-- The Paul Mellon Centre for Studies in British Art
-
-### Data hosting for public sector organisations
-Some local authorities can have dedicated open data portals for hosting information published by the council or about the local area, which are ideal places to host 360Giving data.
-
-Alternatively, public sector organisations may be able to use the central data.gov.uk website to host their 360Giving data.
-
-Examples of public sector data hosting pages:
-- Greater London Authority
-- Stockport Metropolitan Borough Council
-- Sheffield City Council
-
-## Submit your file to the Data Registry
-Once your 360Giving data file is published, the final step is to let us know so the link to the file can be added to the 360Giving Data Registry which is a list of all the organisations that currently publish their grants data in the 360Giving Data Standard.
-
-The 360Giving Data Registry is the source for the grant information in GrantNav, GrantVis and other tools and platforms using the data. Anyone can access this information to view, download and use the data via the 360Giving Data Quality Dashboard.
-
-Publishers submit their valid 360Giving data files to the Data Registry using the 360Giving data file submission form. See our guidance on [how to submit your data to the Registry](../../guidance/submit-data/)
-
-### When your grants will appear in GrantNav and GrantVis
-For data to be included in 360Giving tools, it must meet these criteria:
-- Be included in the 360Giving Data Registry
-- Have an open license
-- Validate against the 360Giving Data Standard schema
-
-**GrantNav** and **GrantVis** are updated on a daily basis. This means your data will appear there the day after a file is submitted to the Data Registry.
-
-## Taking down published data
-A fundamental aspect of publishing using the 360Giving Data Standard, and publishing open data in general, is that once the information is released it may be downloaded and used by anyone.
-
-An organisation is free to decide to stop publishing data and/or can remove the data from their website, however the information that has been published may still be held and used by anyone who has already downloaded it.
-
-360Giving has a Take down policy for the data linked from our Data Registry and loaded into our tools, so we will remove any published data on request.
-
-### Making amendments to published data
-Take down requests are rare. It is however common for publishers to make changes to published data to correct errors or make updates when changes are made to a grant. In addition to changes you make to your own data, you may receive requests from grantees to amend information about their organisations that might be incorrect or misleading. See our [guidance on making updates](../../guidance/making-updates/) to your data and the mechanism for grantees to request amendments.
-
-```eval_rst
-.. _alternative-hosting-options:
-```
-
-## Alternative hosting options
-It is best practice for organisations to host their own data, so the ownership of the information is clear. This gives you full control over the file so you can make changes and updates whenever you need to.
-
-However, for organisations without a website or without capacity to create a place to include the data, it is possible to use alternative hosting and open licensing arrangements. These are described below.
-
-### Include open licensing information into your 360Giving data file
-If you can upload the 360Giving file into the backend of your website but cannot add the license text to a public page – in the short or longer term – you can include the open license information within the file itself using the Metadata sheet (or Package Schema if you are using JSON file format to publish).
-
-Please see our [guidance about metadata](../technical/metadata) for further information.
-
-### Hosting your data using cloud storage
-Below is a step by step guide to using two file sharing services to host 360Giving data; Google Drive and Dropbox.
-
-### Google Sheets
-Google provides users with the Google Drive service, offering 15GB of space for free.
-
-To share a 360Giving data file using Google Drive, it must first be converted to a Google Sheets document.
-
-1\. On your Google Drive, create a new Google Sheets document. Select New > Google Sheets.
-
-2\. Import your 360Giving Excel or CSV file to the Google Sheets. Select File > Import > Upload, and select the file from your computer or drag-and-drop.
-
-
-
-
-
-3\. If you are using an **Excel file** choose 'Replace Spreadsheet' and click Import data.
-
-
-
-
-
-4\. If you are using a **CSV file** choose 'Replace Spreadsheet' as your import option. Choose Separator type as 'Detect automatically' and answer 'Yes' to 'Convert text to numbers and dates' and click 'Import data'.
-
-
-
-
-
-5\. If included in your data check the **Recipient Org:Charity Number** and **Recipient Org:Company Number** columns. Google Sheets will sometimes interpret these columns incorrectly and place decimal points into them. There is a simple fix by selecting the whole column (click the column letter) and then using the menu to select Format > Number > Plaintext.
-
-
-
-
-
-6\. You can rename the file with your prefered title with File > Rename.
-
-7\. Share your file so that it is publically accessible to anyone with the link. Select Share > Get Shareable Link. Choose the Link Sharing option 'On - anyone with the link can view'.
-
-
-
-
-
-8\. Copy the file, which will resemble the following example with 'usp=sharing' at the end:
-
-https://docs.google.com/spreadsheets/d/1gyyHFzS60yrMqindaaTNW8kSFa0sOIZAjDIR8sZ5dLA/**edit?usp=sharing**
-
-9\. Change the end of the link to **export?format=xlsx**, so that is looks like the following example:
-
-https://docs.google.com/spreadsheets/d/1gyyHFzS60yrMqindaaTNW8kSFa0sOIZAjDIR8sZ5dLA/**export?format=xlsx**
-
-10\. Copy this newly-formatted link and test that your data is still valid using the 360Giving Data Quality Tool.
-
-11\. Contact 360Giving Helpdesk via
-
-
-
-
-
-
-Read our guidance about [how to use the codelists](../technical/codelists) for further information about what to consider when adding the **For Regrant Type** field and **Regrant Type** codes to 360Giving data.
-
-
diff --git a/documentation/guidance/submit-data.md b/documentation/guidance/submit-data.md
deleted file mode 100644
index da35cf73..00000000
--- a/documentation/guidance/submit-data.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# Submit your data to the Registry
-Once 360Giving data has been published by an organisation, the file must be added to the 360Giving Data Registry so that the data appears in 360Giving’s tools, including GrantNav and GrantVis.
-
-Publishers of 360Giving data can add their valid 360Giving data files to the Data Registry using the 360Giving data file submission form.
-
-The form allows users to:
-- Update an existing Data Registry entry with an updated version of an existing file
-- Add an entry for a new file to the Data Registry
-
-Only publishers with an authorised website domain can use the data file submission process.
-
-## Authorised domains
-By default, the website domain used by existing publishers to host their 360Giving data files will be authorised.
-
-Organisations that publish 360Giving data for the first time can also use the 360Giving data file submission process once they have registered their website domain with 360Giving. To register your website domain prior to publishing for the first time, please contact the 360Giving Helpdesk at | Identifier | -Description | -Amount Awarded | -For Regrant Type | - - -
|---|---|---|---|
| 360G-ExampleFdn-001 | -Contribution to pooled fund for charities supporting local residents | -50000 | -FRG040 | -
| 360G-ExampleFdn-002 | -Contribution to salary of benefits adviser | -10000 | -- |
| 360G-ExampleFdn-003 | -To be awarded as grants to small arts organisations | -25000 | -FRG010 | -
| 360G-ExampleFdn-004 | -To fund outdoor play equipment for nursery | -5000 | -- |
-
-### GrantVis
-**Understand funders better**
-
-GrantVis is a free tool to help you understand funders better. You can combine and visualise 360Giving and charity data, and explore funding across seven different areas – from grant dates to types of recipients.
-
-
-
-### 360Giving Data Quality Dashboard
-**See the list of all 360Giving publishers**
-
-The Data Quality Dashboard shows the key features that make data useful. You can use the Dashboard to understand individual funders’ data, as well as the 360Giving dataset as a whole. It includes a list of all the organisations that currently publish their grants data in the 360Giving Data Standard, with direct links to their data sources.
-
-
-
-## Support for complex data needs
-Visit our website to find out the different ways that developers, researchers and others can access grants data in the 360Giving Data Standard.