How to Export All Data from Creatio CRM: Methods & Limits

There is no single "Export Everything" button in Creatio CRM. The native Export to Excel feature covers section lists and details — but it hard-caps at 20,000 rows by default. The OData and DataService APIs share that same 20,000-record ceiling per request, and both have RAM and timeout constraints that silently kill large extractions. Attachments require a separate extraction workflow. Configuration metadata requires yet another.

If your goal is a complete, migration-ready extract — to move to Salesforce, HubSpot, Dynamics 365, or any other system — you need to understand each path, its limits, and where it breaks.

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

Using the Native "Export to Excel" (and Its 20,000-Row Limit)

The built-in export is the path most Creatio users try first. It works for small lists. It fails for anything migration-scale.

How it works

Export Creatio data displayed as a list to an .xlsx file for processing and further use. Export to Excel is available for section lists, details, and "List" dashboards.

To trigger it:

1. Navigate to any section (Contacts, Accounts, Opportunities, etc.).
2. Open the Actions menu.
3. Click Export to Excel.

After you run the Export to Excel action, Creatio will download the file that contains every list record. If you specify records via multiple selection, the file will contain only the selected records. Creatio will export only the columns that are displayed in the list.

That last point matters: if a column isn't visible in your current list view, it won't appear in the export. Add all required columns before you run the export. Creatio also does not export contact photos or account logos through this path. (academy.creatio.com)

Creatio stops the export if it runs longer than 10 minutes by default. (academy.creatio.com)

The 20,000-row cap

The MaxEntityRowCount parameter controls the maximum rows per export. Maximum number of records that you can obtain by request is specified in the MaxEntityRowCount (the default value is 20000).

To change this, modify the MaxEntityRowCount parameter in the %Terrasoft.WebApp\Web.config folder, clear Redis, and restart the application. That works for on-premise deployments. If the application is deployed on-demand, you need to contact support to increase the value of the MaxEntityRowCount parameter.

CSV encoding gotcha

If you export to .csv instead of .xlsx, expect string-break issues unless encoding is configured. Check the value of the "Encoding when exporting to '.csv'" system setting. Change the default value to, for example, UTF-8, or any required encoding. Automatic data distribution by strings depends on the regional settings of Excel, as well as on the "Delimiter when exporting to '.csv'" system setting. String breaks due to the presence of special characters that Excel processes incorrectly.

Without UTF-8 encoding, commas or line breaks inside text fields push data into the wrong columns, corrupting your export.

Permissions

You must have permission to the "Export list records" (the CanExportGrid code) system operation to export the list. This is section-level only — column-level export restrictions are not natively supported. If GDPR is a concern, this gap matters.

Authenticating Against the Creatio API

Every programmatic extraction path requires an authenticated session. Creatio supports two authentication mechanisms for API access.

Cookie-based authentication is the default for on-premise and cloud instances. You POST credentials to the login endpoint, receive a session cookie, and include that cookie in all subsequent requests:

POST https://{your-instance}.creatio.com/ServiceModel/AuthService.svc/Login
Content-Type: application/json
 
{"UserName": "your_user", "UserPassword": "your_password"}

The response sets a .ASPXAUTH session cookie. Include it in every OData or DataService request. Sessions expire based on your instance's timeout configuration — long-running extraction scripts must handle re-authentication when a session expires mid-run.

OAuth 2.0 is available on Creatio 8.x cloud instances and is the recommended approach for production integrations. It uses standard authorization code or client credentials flows and returns a bearer token:

GET {CreatioURL}/0/odata/Contact
Authorization: Bearer {access_token}

For service account setup, Creatio requires the account to have the CanExportGrid system operation permission and read access to every object you intend to export. A least-privilege service account with explicit object-level permissions is safer than using an admin account for automated extraction.

Extracting Data Programmatically: OData vs. DataService API

When the UI limits block you, the API is next. Creatio offers two main API families for data extraction. Choosing the wrong one wastes weeks.

OData API (v3 and v4)

Creatio supports OData 4 and OData 3 protocols. OData 4 provides more features than OData 3. Creatio recommends using OData 4 for integrations.

The OData 4 endpoint follows this pattern:

GET https://{your-instance}.creatio.com/0/odata/{EntityName}

Key request patterns for extraction:

# List available object collections
GET {CreatioURL}/0/odata/
GET {CreatioURL}/0/odata/$metadata
 
# Inventory entity schemas
GET {CreatioURL}/0/odata/SysSchema?$filter=ManagerName eq 'EntitySchemaManager'
 
# Count records without downloading them
GET {CreatioURL}/0/odata/Contact/$count
 
# Pull records in pages
GET {CreatioURL}/0/odata/Contact?$select=Id,Name,Email&$top=1000&$skip=0

Key limitations:

• The response body can contain up to 20,000 records.
• A batch request can contain up to 100 sub-requests.
• The Attachment max size (MaxFileSize code) system setting controls the maximum size of files you can upload using requests. The default value is 10 MB.

There's a critical difference between OData 3 and OData 4 for custom objects. Object access is not supported via the OData protocol version 3. Use the OData protocol version 4 to access objects in an assembly package. Since in current versions of Creatio, assembly packages are the default, any custom objects your team has built recently will be invisible to OData 3. This catches BI tool integrations off guard.

DataService API

The Creatio DataService web service is a RESTful service. However, this service is not always convenient for transferring large amounts of data. With the use of the DataService, the data can be automatically configured in various data formats such as XML, JSON, HTML, CSV, and JSV.

The DataService shares the same row cap: Maximum number of records that you can obtain by request is specified in the MaxEntityRowCount (the default value is 20000).

A key difference: DataService doesn't support transferring file streams. Use OData for transferring files.

Use DataService when you need:

• Alternative output formats like CSV, XML, or HTML
• Creatio-side query logic using SelectQuery, filters, or macros
• Targeted extracts where the query contract is already defined

For general-purpose migration extraction, OData 4 is simpler to operate and easier to parallelize.

Which API to use

Practitioners on the Creatio community have reported DataService as faster than OData for non-file operations for both reading and writing. But without file stream support, OData is unavoidable for attachments.

Discovering Custom Fields and the Usr Prefix

Creatio appends the Usr prefix to all custom fields added via the Studio UI. A field your team named "Lead Source Detail" becomes UsrLeadSourceDetail in the schema. Standard migration scripts that enumerate fields without accounting for this convention will silently miss every custom field in your export.

To discover all custom fields programmatically, query the OData $metadata endpoint and filter for columns with the Usr prefix:

GET {CreatioURL}/0/odata/$metadata

Parse the XML response to find all Property elements whose Name attribute starts with Usr. Alternatively, query SysSchema to find entity schemas with custom columns:

GET {CreatioURL}/0/odata/SysSchema?$filter=ManagerName eq 'EntitySchemaManager'&$select=Id,Name,Caption

For each entity, cross-reference the $metadata output to get the full column list including Usr-prefixed fields. Build this discovery step into your extraction inventory before writing any export queries — otherwise your $select statements will silently omit custom data.

Lookup Tables: Export Order Matters

Lookup tables in Creatio store the reference values used by dropdown fields across your objects — things like account types, case categories, contact roles, and lead sources. They are separate objects, and they must be exported and imported before their parent records.

If you import Contact records before exporting the corresponding lookup data, the lookup ID references in your Contact records will point to IDs that don't exist in the target system. The result is broken foreign key relationships that are difficult to remediate after the fact.

To discover which lookup objects exist in your instance:

GET {CreatioURL}/0/odata/SysLookup?$select=Id,Name,SysEntitySchemaName

This returns the list of registered lookups and the entity schema each one is tied to. Export all lookup tables first, remap their IDs to the target system's values, then export parent records.

Common lookup objects to export early in your extraction sequence: ContactType, AccountType, LeadStatus, CaseCategory, ActivityType, OpportunityStage. Custom lookups created in Studio follow the same Usr prefix convention — include them in your SysLookup discovery query.

The Hidden Constraints: RAM Limits, Pagination, and Timeouts

Hitting the 20,000-row limit is the first wall. RAM limits are the second — and less obvious — wall.

OData RAM consumption limit

Starting with version 8.1.4, Creatio introduced a RAM cap on OData requests. If an OData request for data retrieval consumes more RAM size than specified in the "RAM limit for data selection via OData" (MaxMemoryUsageToGetDataViaEntityCollection code) system setting, Creatio will interrupt the handling of the request and return the 500 Internal Server Error status code. The default value property of the system setting is set to 2000 (MB).

This means even if you request only 5,000 records, a query that selects wide rows — many columns, large text fields, Rich Text HTML email bodies, lookups — can exceed 2 GB of server-side RAM and fail with a 500 error. There's no partial response. It's all or nothing.

To avoid this, your extraction script must:

• Explicitly request specific columns via $select rather than wildcards
• Dynamically adjust $top pagination size based on the density of the data being queried
• Split Rich Text fields, HTML email bodies, and long description fields into separate extraction passes

Paginating past the 20,000-record wall

Creatio OData API uses $top and $skip to retrieve the data in pages. A typical pagination loop in Python:

import requests
 
BASE_URL = "https://mycompany.creatio.com/0/odata/Contact"
PAGE_SIZE = 5000
offset = 0
all_records = []
 
while True:
    response = requests.get(
        f"{BASE_URL}?$select=Id,Name,Email&$top={PAGE_SIZE}&$skip={offset}&$orderby=Id",
        cookies=auth_cookies
    )
    data = response.json().get("value", [])
    if not data:
        break
    all_records.extend(data)
    offset += PAGE_SIZE
 
print(f"Exported {len(all_records)} contacts")

Use a page size well below 20,000. 5,000 records per page is a reasonable default to stay clear of RAM limits on wide objects. Always include $select to reduce the column footprint, and $orderby on a stable key like Id so reruns produce consistent, comparable results. The retrieval of paged data via $skip and $top parameters was sped up for OData 4 protocol in version 7.18.1, but performance still degrades on broad queries.

Skip-based paging drift on live systems

If you run extraction against a live system with constant writes, $skip-based paging can drift between passes. Records added or deleted between pages cause duplicates or gaps. This isn't a Creatio bug — it's an inherent limitation of offset pagination on a moving dataset. For migration extractions, schedule the heaviest pulls outside business hours or coordinate a freeze window.

Live Update: the silent performance killer

If your instance slows to a crawl during extraction, Creatio's Live Update feature may be the cause. The unresponsiveness after loading a lot of data is due to Creatio's live update feature. Basically, many Creatio objects have live update enabled, which means for any add or update, it sends a signal back to the browser so the browser reloads the UI. When loading in a large set of data, that causes a socket back to the browser for every single add or update.

Go to the features page https://yourcreatiosystem/0/flags then search for the feature called LiveEditing and disable it.

Exporting Attachments and Binary Files

Attachments are the single hardest data type to extract from Creatio. There is no bulk download button.

The OData 4 File API (Creatio 8.3.2+)

Since version 8.3.2, Creatio provides a dedicated API exposed via OData 4 for managing files. The API enables CRUD operations for files stored either in the Creatio database or in an external file storage, such as AWS S3 or Azure Blob storage.

Files are stored in entity-specific objects: "Contact attachment" (ContactFile code), "File and link of activity" (ActivityFile code), "File and link of account" (AccountFile code) provide a direct foreign-key link to the parent record. Other common file objects include OpportunityFile, CaseFile, and SysFile (the generic file object for custom apps).

For entity-specific objects like ContactFile, the parent link is a direct foreign key like ContactId. For SysFile, Creatio uses RecordSchemaName plus RecordId instead. (academy.creatio.com)

To download a contact's attachment via OData 4:

# List file metadata
GET {CreatioURL}/0/odata/ContactFile?$select=Id,Name,ContactId
 
# Download file binary
GET {CreatioURL}/0/odata/ContactFile({fileId})/Data
 
# Generic file pattern
GET {CreatioURL}/0/odata/SysFile({fileId})/Data

You query the metadata to get file IDs first, then download each file individually. There is no batch file download endpoint. For organizations with tens of thousands of attachments, this becomes a multi-day extraction job. One community case projected nearly 10 days to extract 130,000 attachments via OData.

External file storage

Notes are not the same as file binaries

The Attachments and Notes tab in Creatio can store Rich Text note content, images, and links alongside file attachments. Treat note bodies as data objects that need their own export pass. Rich Text content is exactly the kind of payload that triggers OData RAM limits, so test notes extraction separately from file downloads. (academy.creatio.com)

Pre-8.3.2 instances

If your Creatio version is older than 8.3.2, the dedicated OData 4 File API doesn't exist. Developers in this situation typically use the FileApiService or create custom SQL views that cast binary attachment data to base64 strings for external consumption. Both approaches require significant engineering effort to map extracted files back to their parent records.

Exporting Custom Objects and Configuration Metadata

If your goal is migration — not just a data dump — you need more than row data. Creatio separates business data export from configuration delivery.

For metadata and customizations, Creatio's IDE exports packages as a .zip archive containing a .gz package archive, and individual schemas can be exported as .md files. Creatio explicitly states that the Custom package cannot be transferred between instances. (academy.creatio.com)

A full migration typically requires two parallel workstreams:

• Record data: Accounts, Contacts, Activities, Cases, custom objects, junction tables, notes, files
• Configuration artifacts: Custom objects, fields, pages, business processes, schemas

Package export is a configuration delivery mechanism, not a substitute for customer data export. Plan them as separate tasks from the start.

Third-Party Marketplace Tools for Creatio Exports

If building paginated OData scripts is too resource-intensive, the Creatio Marketplace offers third-party tools. They solve different problems and come with their own trade-offs.

Starfish ETL (Connect Creatio)

StarfishETL and Creatio have partnered to release Connect Creatio, a migration and integration tool specifically designed for Creatio customers. Connect Creatio, powered by StarfishETL, is a low code iPaaS that can help you connect over 200 applications to your Creatio instance.

Starter templates cover common objects: Accounts, Account parents, Contact, Cases, Leads, Products, Opportunities, Opportunity Line Items, Tasks, Events, Notes, and Attachments.

Pricing: StarfishETL 60-Day Migration license is $1,495.00. Additional months are $400.00 per month.

Best for: Teams that need a visual, low-code approach to move data into or out of Creatio, or sync between Creatio and an external system. It handles extraction well but requires configuration knowledge. It is not a one-click dump.

Excel Reports Builder for Creatio

Excel reports builder for Creatio extends Creatio data exporting capabilities. With this application, users can easily set up any dataset to be exported from Creatio — to get any kind of aggregation and analytics based on your formatted Excel spreadsheet with formulas and graphs as a template for your report.

Reports can be based on data from any object (section, detail, lookup, system view or table). However, the Excel reports builder is a free add-on with no official support. Community members report issues with custom sections and Leads. Excel templates with macros are not supported. (marketplace.creatio.com)

Best for: Scheduled, structured reports for business users. Not designed for full database extraction.

Database Backup Approach (Cloud)

For cloud-hosted instances with millions of records, some teams bypass the API entirely. The idea is that you request a database backup from support, then do the migration directly to the database itself, then provide the database back to support to put back in place in the cloud. This was significantly faster to load using SQL inserts than loading record by record via the API. If both the Creatio database and the source database are the same type of database such as MSSQL or Postgres you can load millions of records into tables in seconds.

Keep in mind that if a customer is first a cloud customer, the backup you get from support is likely going to be a PostgreSQL database, not MSSQL.

This approach gives you the entire database, but it skips the Creatio object model — record access rights, business process triggers, and attachment references stored in external file storage won't be handled automatically.

Why DIY Creatio Exports Fail at Scale

We've seen teams attempt full Creatio extractions with custom scripts and hit the same walls repeatedly:

1. The 20k ceiling on every API surface. The UI, OData, and DataService all share the same MaxEntityRowCount default. Pagination works but multiplies request count by 10–50x.

2. RAM errors on wide objects. Custom objects with 100+ columns or large text fields trigger the MaxMemoryUsageToGetDataViaEntityCollection limit. Narrowing $select helps but requires knowing the exact column list for every entity.

3. Attachments are a separate extraction. Every parent object has its own *File table. There's no unified file export endpoint.

4. Relational integrity breaks on flat export. The UI export gives you flat columns. Account → Contact → Opportunity hierarchies, lookup references, and custom object links are lost. Reconstructing them requires mapping IDs back to source records.

5. Assembly package visibility. Custom objects in assembly packages (the default in current Creatio versions) are invisible to OData 3 clients. This silently drops custom entities from your extraction.

6. Custom field naming conventions. Custom fields in Creatio are appended with the Usr prefix in the schema. Standard AI-generated scripts don't account for this, leading to field-mapping failures.

7. Configuration metadata is forgotten. Teams export data but forget packages, schemas, and process definitions — then discover they can't rebuild custom objects in the target system.

For a deeper look at why generic scripts break on platform-specific constraints like these, read Why DIY AI Scripts Fail and How to Engineer Accountability.

How to Plan a Full Creatio CRM Export

The right extraction path depends on your instance setup. Work through these questions first:

• Cloud or on-premise? On-premise instances can modify MaxEntityRowCount directly. Cloud instances require a support request.
• How many records per object? Objects under 20,000 rows can use the UI. Anything larger requires paginated API extraction.
• Do you have attachments? If yes, and your instance is 8.3.2+, plan a separate OData File API extraction pass. Older instances need FileApiService or custom SQL.
• Are there custom objects? Inventory them via SysSchema and verify they are accessible via OData 4 (not OData 3) before writing extraction queries.
• Does your target system require lookup remapping? Export all lookup tables before parent records and remap IDs before import.

Once you have answers to those questions, follow this sequence:

Step 1: Inventory your objects

List every section, detail, lookup, and custom object you need. Include attachment tables (ContactFile, AccountFile, OpportunityFile, SysFile, etc.). Don't forget system objects like Activities and Emails. Use OData metadata ($metadata and SysSchema) for discovery rather than relying on memory. Use the $metadata endpoint to discover all custom fields with the Usr prefix — do not rely on manual field lists. (academy.creatio.com)

Step 2: Choose your extraction method per object type

• Structured data (< 20k rows per object): Native Export to Excel works. Verify all columns are visible in the list first.
• Structured data (> 20k rows): Paginated OData 4 with $top / $skip. Use a page size of 5,000. Include $select to stay under RAM limits.
• Attachments: OData 4 File API (8.3.2+). Enumerate file metadata first, then download binaries individually.
• Rich Text / HTML fields: Extract in a separate pass with reduced page sizes.
• Full database (millions of records): Request a database backup from Creatio support.
• Configuration metadata: Package/schema export through Creatio IDE.

Step 3: Configure encoding and format

If any downstream system expects CSV:

• Set "Encoding when exporting to '.csv'" to UTF-8
• Set "Delimiter when exporting to '.csv'" to ; (semicolon)

Step 4: Validate relational integrity

After extraction, verify that lookup IDs in child records (e.g., AccountId on Contacts) actually resolve to records in your exported parent tables. Missing parents = broken relationships in the target system.

Step 5: Test before the full run

Export a single object with known record counts. Compare the export count against the Creatio section filter count using $count. If they don't match, you're hitting a limit or permission filter.

If you're preparing for import into the target system, use our Data Migration Checklist to map your strategy.

When to Bring in Help

If your Creatio instance has more than 50,000 records across objects, custom objects with nested lookups, or significant attachment volumes — a scripted export is a multi-week engineering project, not a weekend task.

At ClonePartner, we've built paginated extraction pipelines that handle Creatio's OData RAM limits, file-by-file attachment downloads, assembly package discovery, and relational integrity mapping — delivered in days with zero downtime.

If you're hitting the limits described in this guide, we can help.