How to Export All Data from 360 View CRM: Methods & Limits (2026)

There is no single "Export Everything" button in 360 View CRM. The built-in reporting tools can pull flat lists of customers or accounts into spreadsheets, but they strip the relational context — deposit signers, loan guarantors, household ties, referral chains — that makes banking CRM data useful. The REST API covers the core objects (customers, accounts, referrals, incidents, pipelines, activities), but requires an API license, OAuth 2.0 setup, and custom pagination logic. And if you're running 360 View on-premise behind a bank firewall, your extraction options change again.

If your goal is a complete, migration-ready extract — to move to Salesforce Financial Services Cloud, Dynamics 365, or another platform — you need to understand each path, its limits, and where it breaks.

For context on why flat CSV files struggle with relational CRM data, see our breakdown of Using CSVs for SaaS Data Migrations.

Why Exporting Data from 360 View CRM Is Uniquely Complex

360 View is not a general-purpose CRM. Designed for the financial industry from the ground up by experienced bankers, 360 View goes beyond CRM. Its data model reflects the way banks and credit unions actually operate — which makes extraction harder than most teams expect.

Banking-specific objects you must account for

Open Referrals, Pipelines, and Incidents and To-Do items, cross-sell opportunities, household relationships, direct relationships, center of influence relationships, deposit-signers, and loan-guarantors — these are first-class objects in 360 View, not custom fields bolted onto a generic contact record.

Here's what that means for extraction:

• Referrals are bidirectional. Referral tracking and management is at the heart of the 360 View system. Here you can easily create referrals directly from customer or prospect inquiry and send them to other employees or departments in seconds. Each referral has a creator, a recipient, a status, a product, and a customer — five foreign keys minimum.
• Pipelines carry loan workflows with stage assignments, close probabilities, and branch associations. Open a new pipeline for loans or other products on any customer or prospect. Build your existing workflow into 360 View Pipelines while assigning security and close probability.
• Deposit signers and loan guarantors are relationship types between customers and accounts — not separate tables you can pull as a flat CSV. The ability to see relationship ties on an account owner, deposit signers, and spheres of influence in one place provides better information for member evaluation and servicing.

If John Doe is a primary signer on a checking account, a guarantor on a small business loan, and the originator of an internal mortgage referral, those are three distinct relational links. A CSV export will give you a customer name and an account number in the same row, but it won't tell you how that customer is connected to that account. That distinction matters for compliance, for relationship continuity, and for mapping into your target CRM.

The Abrigo acquisition factor

On March 6, 2026, Abrigo, a leading provider of compliance, credit risk, lending, and data and analytics solutions for U.S. financial institutions, acquired 360 View. The acquisition marks the latest in a series of strategic investments by Abrigo to help financial institutions deepen customer relationships and drive measurable growth.

This matters for your export planning. As part of the acquisition, employees from 360 View will join Abrigo, and customers of the platform will continue to receive uninterrupted service. But roadmap uncertainty is real. If you're planning a migration away from 360 View, start your data extraction planning now — before any potential API changes, pricing shifts, or platform consolidation.

System-of-record drift and permissions

360 View integrates with over 15 core banking systems and records CRM-native history such as referrals, incidents, activities, Outlook-synced email and calendar items, and Constant Contact marketing events on customer or prospect records. (360view.com) Before you export, decide which fields are authoritative in 360 View and which are mirrored from the core or another system.

Permissions can also distort your extract. 360 View allows institutions to roll modules out in stages and limit access by role — for example, Pipeline access for lenders but not tellers. (360view.com) If you export with an under-privileged user, you can get a technically successful extract that is still incomplete.

Method 1: Native Reports and CSV Exports

The built-in reporting engine is what most 360 View admins try first. It works for small, flat list pulls. It fails for anything migration-scale or relational.

How it works

360 View includes an easy query tool — the Customer or Account Wizard — for building lists inside the product. Those lists can be exported to CSV for external use. (solutions.icba.org) The platform also includes over 150 standard reports, a custom Report Writer, and scheduled report delivery. Easily condense all sources of customer information into a single view with shareable custom dashboards and reports.

What you get

• Customer lists: Name, contact info, branch assignment, custom field values
• Account summaries: Account numbers, product types, balances (synced from core)
• Activity logs: Flat rows per activity, no nested relationship data
• Referral lists: Status, product, dates — but not the full relational graph

What you lose

• Relational context: A deposit signer on account #4521 will not appear linked to the primary owner in a flat CSV. You'll get two separate rows with no join key.
• System IDs: UI exports often drop the internal database identifiers required to map records together in a target system.
• Nested objects: Referrals tied to a specific customer won't carry sub-activities, comments, or the referred-to employee details in the same export.
• Attachments: Documents and files associated with customer records are not included in report exports.
• History depth: Reports are typically filtered snapshots, not full historical dumps.

When to use it

Native exports are fine for:

• Spot-checking data before a migration
• Pulling a marketing segmentation list
• Giving auditors a quick customer count
• Pre-migration field audits and reconciliation counts

They are not sufficient for a full migration. If your new CRM needs to know that Jane Smith is the primary owner on three checking accounts, the authorized signer on a business account, and the source of four referrals last quarter — a CSV won't carry that.

A practical pattern: use native reports and CSVs for discovery and QA, not as the migration input. Pull one CSV per major business slice, use reports to confirm counts, and compare those counts against API extracts later. That gives you a control plane for reconciliation without pretending the CSV is the source of truth.

Method 2: Extracting Data via the 360 View REST API

The API is the primary programmatic extraction path. With 360 View API, you can query main CRM objects (customers, accounts, referrals, incidents, pipelines, activities) and add/update any of those objects. This allows you to integrate to any of your 3rd party systems.

Prerequisites

The 360 View uses the OAuth 2.0 protocol for authorization. This is an industry-standard protocol that is used to keep applications and their data secure. This protocol allows an application to obtain an "access token" which grants access to API endpoints. Before requesting an "access token" the application must first be registered with 360 View. This can be done via the API Maintenance form. Access to this form requires a 360 View API focus plan which has to be added to your 360 View installation by our support department.

In plain terms, you need:

1. A 360 View API license (the "API focus plan") — contact 360 View / Abrigo support to activate it
2. A registered OAuth 2.0 client created via the API Maintenance form
3. An access token obtained through one of the supported OAuth 2.0 flows

Supported OAuth 2.0 flows

For a bulk data extraction script, the Resource Owner Password flow is the practical choice — it runs headlessly and doesn't require a browser redirect.

API structure and pagination

The API follows a RESTful resource/{id}/subresource pattern:

GET https://{your-api-url}/api/customers/{customerId}/referrals?pageSize=25&pageNo=3

Resources are typically nouns like 'customers' or 'referrals' that you take actions on using supported HTTP verbs. The root directory for the API includes a map of all available resources and their subresources. Each resource is typically separated into a resource/{id} format, with subresources following the same pattern.

Pagination uses pageSize and pageNo query parameters. The default page size is 25. There is a maximum page size enforced server-side to prevent performance degradation — this limit is adjustable by 360 View support but is not publicly documented.

Rate limits and timeouts

Two constraints you'll hit during bulk extraction:

• Throttling: The API implements per-second rate limiting to protect the core application's performance. The exact threshold is not public — if your extraction is getting throttled, contact support to discuss adjustment.
• Timeouts: The default timeout is 30 seconds per request. Large result sets or complex queries on a busy server can hit this. 360 View support can increase it, but the recommendation is to keep page sizes small and paginate aggressively.

What the API covers (and what it doesn't)

Covered:

• Customers (with custom fields)
• Accounts
• Referrals (including status, product, referring employee, referred-to department)
• Incidents (service requests)
• Pipelines (loan workflows, stages, close probability)
• Activities (calls, meetings, tasks)

Not covered or requires verification:

• File attachments: No documented bulk file download endpoint. Attachments likely require individual retrieval per record.
• Marketing campaign history: Email delivery, open, bounce, and click data is recorded on customer records, but bulk extraction of campaign analytics may require separate handling.
• Profitability and analytics modules: If you have 360 View's Profitability or Actionlytics add-ons, that data may not be exposed through the standard CRM API endpoints.
• Profiles and custom Q&A: 360 View documents profile management, but the public API object list does not explicitly name profiles. (360view.com) Test this early instead of assuming it's covered.

Recommended extraction order

A solid extraction sequence follows this pattern:

1. Base party data first: Customers, prospects, statuses, timestamps, owners
2. Accounts and relationship keys: Financial products with foreign keys tied to parties
3. Workflow objects: Referrals, pipelines, incidents, activities
4. Extended modules: Profiles, custom Q&A, marketing data — test API coverage for these early since the public docs don't explicitly confirm they're all exposed (360view.com)
5. Delta extract: Run a final pass close to cutover to capture records created or modified during the migration window

Sample extraction workflow

import requests
import json
import time
 
BASE_URL = "https://your-360view-api-url/api"
TOKEN = "your_oauth_access_token"
HEADERS = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/json",
    "Content-Type": "application/json"
}
 
def extract_all_customers(page_size=25):
    """Paginate through all customers."""
    all_customers = []
    page = 1
    while True:
        resp = requests.get(
            f"{BASE_URL}/customers?pageSize={page_size}&pageNo={page}",
            headers=HEADERS,
            timeout=30
        )
        resp.raise_for_status()
        batch = resp.json()
        if not batch:
            break
        all_customers.extend(batch)
        page += 1
        time.sleep(0.5)  # Respect throttle limits
    return all_customers
 
def extract_referrals_for_customer(customer_id, page_size=25):
    """Pull all referrals for a given customer."""
    referrals = []
    page = 1
    while True:
        resp = requests.get(
            f"{BASE_URL}/customers/{customer_id}/referrals?pageSize={page_size}&pageNo={page}",
            headers=HEADERS,
            timeout=30
        )
        resp.raise_for_status()
        batch = resp.json()
        if not batch:
            break
        referrals.extend(batch)
        page += 1
        time.sleep(0.5)
    return referrals

Method 3: Direct SQL Server Access (On-Premise Only)

The 360 View CRM Platform can be hosted within your organization, or we can host it for you. If your institution runs 360 View on-premise, you have an option that cloud-hosted customers don't: direct access to the underlying Microsoft SQL Server database.

With a web-based front-end and Microsoft SQL Server database back-end, this software solution can reside on your internal network server or be hosted for unlimited access by your employees.

What direct SQL gives you

• No API rate limits or pagination overhead — query the entire dataset in one pass
• Full relational integrity — JOIN deposit signers to accounts to customers in a single query
• Attachment BLOBs — binary file data stored in SQL can be extracted directly
• Profitability and analytics data — tables that may not be exposed through the API

The risks

• No official schema documentation — 360 View's internal table structure is not publicly documented. You'll need to reverse-engineer it or work with 360 View / Abrigo support.
• Upgrade breakage — Direct SQL queries can break when 360 View pushes schema changes. This is not a supported extraction path.
• Compliance exposure — Banks have strict controls around who can access production SQL servers. Your DBA team, information security officer, and possibly your regulator will need to be in the loop.

On-Premise vs. Cloud: How Hosting Impacts Your Export

Your extraction strategy depends heavily on where your 360 View instance lives.

On-premise extraction path

1. Clone or snapshot the SQL Server database
2. Query the cloned database using SQL Server Management Studio
3. Export result sets to CSV, JSON, or directly into your migration pipeline
4. Use the API for any data not accessible through SQL (rare, but possible for some computed fields)

For banks that need to extract data from behind a firewall without exposing anything to the public internet, see ClonePartner Envoy: the on-prem migration agent.

Cloud-hosted extraction path

1. Use the REST API for all structured data (customers, accounts, referrals, pipelines, incidents, activities)
2. Request a data dump from 360 View / Abrigo support for anything the API doesn't cover
3. Download attachments individually via the API or coordinate with support

For banks with strict data residency requirements, the cloud extraction path raises questions about where data transits during export. See Dynamics 365 Data Sovereignty: How to Migrate Without Your Data Ever Leaving the Network for a framework that applies to any banking CRM migration.

Mapping 360 View Banking Objects to Your New CRM

The hardest part of a 360 View migration isn't extraction — it's mapping. 360 View's banking-specific objects don't have 1:1 equivalents in general-purpose CRMs.

360 View → Salesforce Financial Services Cloud

Salesforce FSC has the better native fit for banking relationship graphs because its published models include Person Account, Household, Account-Contact Relationship, and Financial Account objects. (developer.salesforce.com) For reference on what the FSC data model looks like from the export side, see How to Export Data from Salesforce Financial Services Cloud.

360 View → Microsoft Dynamics 365

Profiles and custom Q&A

360 View documents profile management and unlimited customizable Q&A. (360view.com) Don't auto-create a field in the target for every source field. Move only the fields that drive reporting, segmentation, routing, or advisor workflows. Archive the rest or model them as a custom related entity. This avoids field sprawl in the target system.

Enterprise iPaaS: MuleSoft, Boomi

If your bank already runs MuleSoft or Boomi for other integrations, you can build a 360 View connector using the REST API. A CRM that supports API integrations and has an open architecture will allow these institutions to continue using their existing tools while benefiting from enhanced CRM functionalities.

Practical constraints:

• No pre-built 360 View connector exists on MuleSoft Exchange or Boomi's connector library as of early 2026. You'll be building a custom REST connector from scratch.
• The same API limits apply. An iPaaS doesn't bypass the throttling, timeout, or pagination constraints. It just gives you a GUI to manage the extraction flow.
• Cost. MuleSoft and Boomi licensing for a one-time migration is expensive. If you're not going to use the iPaaS after the migration, the ROI doesn't make sense.

An iPaaS makes sense if you need ongoing sync between 360 View and another system. For a one-time extraction and migration, the API + custom script approach (or a migration partner) is faster and cheaper.

Practical Extraction Checklist

Before you start pulling data:

• Confirm your API license. Contact 360 View / Abrigo support to verify the API focus plan is active.
• Register your OAuth 2.0 client. Use the API Maintenance form to create a client for your extraction tool.
• Verify permissions. Ensure your extraction account has visibility into every module and business line. Under-privileged users produce incomplete extracts.
• Identify all object types. Don't just export customers. Map every 360 View module your bank uses: referrals, pipelines, incidents, activities, marketing campaigns, goals, profiles.
• Document custom fields. 360 View allows custom field creation. Export the field definitions alongside the data.
• Determine hosting model. On-premise or cloud? This dictates your extraction method.
• Inventory attachments. Count the total file volume. Plan a separate extraction workflow.
• Clarify system-of-record boundaries. Decide which data to extract from 360 View vs. from your core banking system directly.
• Plan for delta sync. If the migration takes days, you need a way to capture records created or modified after your initial extraction.

The ClonePartner Approach

We've handled CRM migrations for financial institutions where the data model is anything but standard. 360 View's banking-specific objects — referrals, deposit signers, loan guarantors, pipeline stages — require careful mapping that off-the-shelf migration tools don't support.

Here's how we approach a 360 View extraction:

• API-first extraction with custom pagination, retry, and rate-limit handling built into our scripts
• On-premise support via ClonePartner Envoy: For banks running 360 View on-premise, our lightweight agent runs inside your firewall — data never leaves your network during extraction
• Pre-built mapping templates for translating 360 View objects into Salesforce FSC, Dynamics 365, and HubSpot target schemas
• Zero-downtime continuous sync so your bank staff keeps working in 360 View while we populate the new CRM in parallel
• Validation and reconciliation — record counts, referral chain integrity, signer role verification — before cutover

If your team is evaluating a move away from 360 View — especially post-acquisition — we can scope the extraction and mapping in a 30-minute call.