Your Database Has the Record. Maisy Explains What Staff Should Do With It

Nonprofits often expect too much from their databases and too little from their organizational knowledge.

A case-management system may contain participant records. A donor database may contain gift history. An accounting system may contain transactions. An HR system may contain employee information.

These systems are designed to store and manage records.

They do not always explain:

• Which system employees should use
• When a record must be created
• Which fields are required
• Who reviews the information
• How errors should be corrected
• Which approval is needed
• What staff should do when information conflicts
• When an issue must be escalated
• Which policy governs the process

That guidance often lives somewhere else.

It may be found in procedure manuals, training documents, emails, Teams messages or the memory of an experienced employee.

Maisy helps nonprofit employees find the approved procedures and institutional knowledge surrounding their systems without replacing the systems themselves.

The Difference Between Data and Guidance

A database answers questions about records.

For example:

• What services did this participant receive?
• When was this donation recorded?
• What is the status of this volunteer application?
• Which invoice was paid?
• When did this employee complete training?

A knowledge hub answers questions about how the organization expects work to be performed.

For example:

• When should a participant record be created?
• Which gift type requires development-director review?
• What documents must be collected before approving a volunteer?
• Who corrects an accounting error?
• Which training is required for this employee’s role?

These are different types of questions.

The source system remains authoritative for individual records and transactions.

Maisy provides easier access to the approved guidance employees need when creating, reviewing and using those records.

A Realistic Nonprofit Example

Consider a nonprofit with 60 employees operating several programs across three locations.

The organization uses:

• A case-management system
• A donor database
• Accounting software
• A volunteer-management platform
• An HR system
• SharePoint
• Microsoft Teams

Each system performs a legitimate function.

The problem is that employees are not always sure where information belongs.

A program employee records attendance in the case-management system but stores follow-up notes in a spreadsheet.

A development employee updates a donor address in the donor database but maintains mailing preferences in a separate list.

A volunteer coordinator tracks screening status in the volunteer system but keeps exception approvals in email.

Finance records transactions in the accounting system but stores grant coding instructions in a departmental folder.

The nonprofit has several systems of record, but the operating rules surrounding those systems are scattered.

Employees ask questions such as:

• Where should this information be entered?
• Which system contains the official record?
• Can I correct this field myself?
• Who reviews this entry?
• Which report should I use?
• What should I do when two systems disagree?
• When does this need management approval?
• How long must this record be retained?

The database contains data. It does not necessarily contain the organization’s full operating procedure.

Every Important Record Needs an Authoritative Home

A nonprofit should clearly identify which system is authoritative for each major type of record.

For example:

This does not mean data will never appear in more than one system.

A donation may appear in the donor database and accounting software because each system serves a different purpose.

The organization still needs to define:

• Which system owns each field
• How information moves between systems
• Who is responsible for reconciliation
• Which system staff should consult first
• How discrepancies should be resolved
• Which record must be preserved

Without these rules, employees may create unofficial spreadsheets and duplicate databases.

Why Employees Build Shadow Systems

Employees usually create spreadsheets and side lists because the approved systems do not seem to meet an immediate need.

They may believe:

• The official system is difficult to use
• They cannot access the correct report
• The required field does not exist
• The system is too slow
• The procedure is unclear
• Training was incomplete
• Another employee recommended the workaround
• The spreadsheet makes the information easier to see

Some workarounds may be legitimate temporary solutions.

Others create serious problems:

• Duplicate records
• Conflicting totals
• Inconsistent definitions
• Unprotected personal information
• Manual reentry
• Missing audit history
• Dependence on one employee
• Reports that cannot be reproduced
• Data that remains after the employee leaves

The National Council of Nonprofits recommends beginning data-risk work by identifying what information the organization collects and where it is stored. That inventory helps leadership understand which systems and unofficial repositories contain sensitive or important information. Its nonprofit cybersecurity guidance provides a useful starting point.

Maisy cannot eliminate shadow systems by itself.

It can make approved instructions easier to find and clarify which system employees should use.

How Maisy Helps Employees Use Existing Systems

An employee might ask:

“Where do I record a participant’s completed intake?”

Maisy could retrieve the approved procedure and explain:

1. The completed intake is entered in the case-management system.
2. Required consent documentation must be uploaded to the participant record.
3. Staff should not save completed forms in the general program SharePoint library.
4. A supervisor must review incomplete eligibility documentation.
5. Technical access problems should be submitted through the approved support process.

Another employee might ask:

“The donor database and accounting report show different totals. Which one is correct?”

Maisy should not decide which total is correct.

It could explain:

• Which system is authoritative for gift history
• Which system is authoritative for financial reporting
• How reconciliation is performed
• Who owns the reconciliation process
• Where discrepancies should be reported

This is the proper role of Maisy: retrieving approved guidance, not inventing a resolution.

Procedures Should Surround the System

Every major organizational system should have an approved set of supporting instructions.

These may include:

Purpose

Explain what the system is used for and what it is not used for.

Record ownership

Identify which department or role owns the information.

Entry requirements

Define:

• When records must be created
• Which fields are required
• Which naming standards apply
• What supporting documentation is needed
• Which deadlines apply

Review requirements

Explain:

• Who reviews entries
• What reviewers should verify
• How errors are returned
• When supervisor approval is required

Correction procedures

Define:

• Who may edit records
• How corrections are documented
• When records should not be overwritten
• Who handles locked or historical records

Reporting guidance

Clarify:

• Which reports are approved
• Who may run them
• Which definitions apply
• When reports should be reconciled
• Who approves external reporting

Escalation

Explain when employees must contact:

• A supervisor
• Finance
• HR
• Technology
• Compliance
• Leadership
• A qualified professional

These instructions are organizational knowledge. SharePoint is generally the appropriate place to organize them for Maisy.

SharePoint Is the Knowledge Source, Not the Transaction System

SharePoint should serve as the primary organized source for:

• Procedures
• Policies
• Definitions
• Training materials
• Blank forms
• System instructions
• Approval guidance
• Reporting calendars
• Escalation rules

It should not automatically become the replacement for every operational database.

For example, SharePoint may contain instructions explaining how to create a participant record.

The completed participant record should remain in the case-management system.

SharePoint may contain donor-entry standards.

The donor’s transaction history should remain in the donor database.

This separation helps maintain a clear source of truth.

Connecting Data Is a Separate Implementation Layer

Some nonprofits will want Maisy to retrieve selected information from databases or external systems.

That may be possible through:

• Copilot connectors
• Power Platform connectors
• APIs
• Dataverse
• Azure services
• Approved reports
• Scheduled exports
• Indexed copies
• Custom integrations

These methods do not all work the same way.

Microsoft explains that Copilot connectors can index approved external enterprise information into Microsoft Graph while respecting source-level permissions. Microsoft’s Copilot connector documentation describes this approach.

Power Platform connectors can provide real-time API access and may support reading data, writing data or triggering actions. Microsoft distinguishes these real-time connections from indexed Copilot connectors in its connector comparison guidance.

A connection should not be treated as a simple checkbox.

Each proposed integration requires discovery.

Questions to Answer Before Connecting a Database

Before connecting Maisy to another system, the nonprofit should determine:

What question is being solved?

“Connect the database” is not a use case.

A stronger requirement is:

“Allow authorized program managers to retrieve the current status of approved service referrals.”

That statement identifies the user, the information and the purpose.

Is current data required?

Some questions can be answered from scheduled reports.

Others require real-time information.

Real-time access may be more complex and may introduce additional licensing, reliability and security requirements.

Which fields are needed?

The integration should expose only the information required for the approved use case.

Maisy may need:

• Record status
• Program name
• Responsible department
• Due date

It may not need:

• Full case notes
• Medical details
• Social Security numbers
• Complete financial history

Data minimization reduces risk.

Who should have access?

Access should follow the source system’s roles and permissions whenever technically supported.

Is the information authoritative?

If the connected source contains incomplete or unreliable data, Maisy will make that poor-quality information easier to retrieve.

What happens when systems disagree?

The organization needs an approved reconciliation procedure.

Who maintains the integration?

Someone must own:

• Credentials
• Connection health
• Permissions
• Field mappings
• Error handling
• Testing
• Updates
• Vendor changes

Start With Read-Only Access

Read-only access should generally come before write-enabled actions.

A read-only connection may allow Maisy to retrieve an approved status or report.

A write-enabled action may allow the agent to:

• Create a record
• Change a field
• Approve a request
• Send information
• Trigger a workflow
• Update a transaction

These actions carry greater risk.

A mistaken answer is a problem.

A mistaken database update may alter an official record.

Before enabling write actions, the nonprofit should define:

• Authentication
• Authorization
• Confirmation steps
• Approval requirements
• Audit history
• Error handling
• Rollback procedures
• Human review
• Testing
• Monitoring

The organization should not enable write access simply because the technology allows it.

Permissions Must Follow the Source

Microsoft states that properly configured SharePoint knowledge sources authenticate users and retrieve only information they already have permission to access. At minimum, users need appropriate read access to the underlying SharePoint source. Microsoft’s SharePoint knowledge-source documentation explains this permission-aware behavior.

External systems may have different security models.

The implementation team must determine:

• Whether the connection uses the employee’s identity
• Whether it uses a shared service account
• Whether source permissions are preserved
• Whether Maisy receives broader access than the user
• Which records can be returned
• Whether the response can include restricted fields
• How access is logged

A shared connection with broad database permissions may create serious exposure if it is not carefully controlled.

Permission-aware access must be verified, not assumed.

Sensitive Records May Need to Remain Outside Maisy

Even when a technical connection is possible, it may not be appropriate.

Sensitive information may include:

• Participant case notes
• Medical information
• Employee records
• Background checks
• Donor payment details
• Legal records
• Investigation files
• Credentials
• Full financial-account information

Maisy may provide general guidance about working with those records.

It does not need to retrieve the records themselves.

The safest implementation may be to direct the employee to the source system.

For example:

“Participant records are maintained in the case-management system. Follow the approved access procedure or contact your supervisor if access is unavailable.”

That answer is useful without exposing the participant’s information.

Maisy Should Not Make Sensitive Decisions

Structured data does not automatically make a decision safe for AI.

A database may contain facts relevant to:

• Program eligibility
• Employment decisions
• Financial assistance
• Medical services
• Legal obligations
• Grant compliance
• Disciplinary action

Maisy should not independently make those decisions.

It may retrieve:

• Approved criteria
• Required steps
• Relevant policies
• Escalation instructions
• The responsible reviewer

A qualified employee must apply professional judgment.

For example:

“The approved procedure requires a program supervisor to review eligibility. Maisy can provide the criteria but cannot make the final determination.”

Human Review Is Necessary When Data Is Incomplete

Database records are often incomplete, delayed or inconsistent.

An employee may forget to update a status. A nightly synchronization may fail. A duplicate record may exist. Two systems may use different definitions.

Maisy should be designed to communicate uncertainty.

Appropriate responses may include:

• “The source does not contain a current status.”
• “This information was last updated yesterday.”
• “The records appear to conflict.”
• “Contact finance for reconciliation.”
• “This question requires supervisor review.”
• “The source system remains authoritative.”

The system should not hide data-quality problems behind a confident answer.

A Practical Starting Point

1. Inventory the systems

List the organization’s:

• Databases
• Spreadsheets
• SharePoint sites
• Department tools
• Reporting systems
• Unofficial tracking files

2. Define the authoritative record

For each information type, identify:

• Source system
• Owner
• Primary users
• Update responsibility
• Reporting responsibility
• Retention requirements

3. Identify repeated system questions

Ask employees:

• Which system should I use?
• Where do I enter this?
• Who reviews the record?
• Which report is correct?
• How do I fix an error?
• What should I do when systems disagree?

4. Organize the procedures in SharePoint

Begin with guidance before attempting complex integrations.

5. Configure Maisy around those procedures

Help employees locate approved answers and the correct source system.

6. Select one structured-data use case

Choose a narrow, useful question with a defined audience.

7. Review technical options

Evaluate connectors, APIs, reports or exports based on:

• Data freshness
• Permissions
• Licensing
• Security
• Complexity
• Maintenance

8. Begin read-only

Confirm that the right users receive the right information before considering actions.

9. Test failure conditions

Test:

• Missing data
• Duplicate records
• Permission denial
• Connection failure
• Outdated data
• Conflicting systems
• Sensitive questions

10. Assign ownership

Someone must own both the procedure and the technical connection.

Expected Organizational Benefits

A clear relationship between Maisy and the nonprofit’s existing systems can help:

• Reduce uncertainty about where information belongs
• Clarify which system is authoritative
• Reduce unofficial spreadsheets
• Improve employee training
• Make system procedures easier to find
• Improve data-entry consistency
• Clarify correction and escalation processes
• Reduce dependence on experienced employees
• Support safer structured-data access
• Preserve source-system permissions
• Identify data-quality problems
• Avoid unnecessary system replacement

The goal is not to combine every system into one giant database.

It is to give employees a clear way to understand which system contains the record and what they are expected to do with it.

Keep the Record Where It Belongs

Maisy helps nonprofit employees find approved procedures, system instructions and institutional knowledge without replacing the databases that contain official records and transactions.

Pixeldust helps nonprofits identify their systems of record, organize the guidance surrounding those systems in SharePoint, review permissions and evaluate selected structured-data connections when they provide a clear operational benefit.

The process begins with discovery: understanding what systems the nonprofit uses, which records each system owns, where employees become confused and whether Maisy should provide guidance, read-only information or simply direct the employee to the authoritative source.