The export is suitable, for example, for data checks, migrations, support cases, duplicate analyses, or simple inventories.

What is exported?

The CSV download exports all records of the currently opened module. The fields of the module are determined based on the web service description and written to the CSV file as columns.

An important advantage: For linked fields, CRM-Snitcher outputs not only the internal CRM IDs wherever possible, but also readable content from the linked record. Instead of an ID such as 11×12345, the CSV may contain, for example, the name of a contact, an organization, or a user.

This makes the exported data much easier to read and reduces the amount of manual post-processing required.

Requirements

Valid web service access credentials are required for the export:

• CRM URL
• CRM user: API or access key of the user, which can be found in the CRM user administration

The access credentials are only kept in the current PHP session in CRM-Snitcher. They are not stored permanently.

Important: The CRM user being used must have web service access to the desired module. In addition, the user can only export the records that they are allowed to see according to the CRM permissions.

Step 1: Open CRM-Snitcher

Open CRM-Snitcher in your browser. After opening it, the login form for the CRM web service connection is displayed first.

Enter the CRM URL, the web service user, and the API key there. After a successful connection, CRM-Snitcher loads the list of modules to which the user has access.

Step 2: Select the desired module

The module overview displays all modules that can be accessed via the web service. Typical examples include:

• Accounts
• Contacts
• Leads
• Potentials
• HelpDesk
• Products
• Services
• Invoice
• SalesOrder

Click the name of the module whose records you want to export.

After clicking, the module view opens. There, CRM-Snitcher displays, among other things:

• the query area for web service queries
• the CSV export area
• the field definitions of the module
• field names, labels, mandatory fields, and field types

Step 3: Start the CSV export

In the module browser, the CSV export section is located below the query block.

There you will find the button: Download all records as CSV

Clicking this button starts the complete export of all records of the currently opened module.

CRM-Snitcher generates the CSV file on the server side and then delivers it directly to the browser as a download.

Note for large amounts of data

For modules with a very large number of records, generating the CSV file may take some time. CRM-Snitcher therefore displays a spinner on the button when the download starts.

This is particularly important for large modules, for example:

• many contacts
• large activity histories
• extensive tickets
• invoices or orders spanning several years
• heavily used custom modules

While the export is being prepared, the page should not be reloaded. Depending on the amount of data, server performance, and number of linked fields, the process may take anywhere from a few seconds to several minutes.

How CRM-Snitcher exports the data

The export runs via the CRM web service interface. CRM-Snitcher does not query the records directly from the database, but instead uses the regular web service operations.

As a result, the permissions of the logged-in user are applied automatically.

In simplified terms, the following happens:

1. CRM-Snitcher loads the field definitions of the module using describe.
2. The CSV columns are built from these definitions.
3. All records of the module are then queried in blocks.
4. Reference fields are detected.
5. Linked records are loaded additionally and converted into readable values.
6. The CSV file is output as a download.

Block-by-block querying is important so that larger modules can also be exported without having to load everything in a single request.

Linked fields are output in a more readable form.

Many CRM fields do not internally contain plain text, but web service IDs. Without resolving these references, such fields would be difficult to read in the CSV. CRM-Snitcher therefore tries to determine a meaningful display name from the linked record for references.

Example:

Instead of: 11×2457

the CSV will contain, wherever possible: Muster GmbH

Or, for contacts: Max Mustermann

If no suitable display name is found or the linked record cannot be loaded, the original ID is retained. This ensures that no information is lost.

Opening the CSV file

The exported file can be opened directly in common programs, for example:

• Microsoft Excel
• LibreOffice Calc
• Apple Numbers
• Google Sheets
• Database or BI tools
• Text editors

The file is output as a UTF-8 CSV so that umlauts and special characters are processed as cleanly as possible.

When opening the file in Excel, depending on the system and language settings, it may be useful to open the file via the import dialog and select UTF-8 as the character set there.

Typical use cases

CSV export via CRM-Snitcher is particularly helpful for:

• quick data analyses
• data cleanup
• duplicate checks
• migrations
• before-and-after comparisons
• support and troubleshooting
• documentation of existing data inventories
• exports from custom modules
• checking reference fields

Since the export runs directly via the web service, no database access is required.

Security and responsibility

CRM-Snitcher is a technical tool for administrators, developers, and experienced CRM users. Even though the CSV export itself is read-only, the tool should be used with care.

Recommendations:

• Use a dedicated web service user wherever possible.
• Check the permissions of this user.
• Export only the data you actually need.
• Treat CSV files containing personal data confidentially.
• Delete local export files when they are no longer needed.
• Use the tool on production systems only deliberately and in a controlled manner.

Conclusion

CRM-Snitcher makes it possible to quickly download all records of any CRM module as a CSV file. The export is particularly useful because it does not only output raw data, but also converts linked fields into readable content wherever possible.

This makes CRM-Snitcher very well suited for analyses, migrations, support tasks, and data checks without requiring direct database access.

This article explains the fundamental principles of our support and billing policy in a clear and understandable manner. In terms of content, it fully corresponds to the binding provisions referenced by our General Terms and Conditions (AGB) and other contractual documents.

Why we introduced this policy

As a SaaS provider for CRM and xRM systems, we operate a powerful standard platform and continuously develop it further. At the same time, we support our customers with individual adaptations, configurations, and extensions.

To ensure fair and predictable cooperation for both parties, a clear distinction is essential:

• Which services are part of ongoing SaaS operations?
• Which services are individual services that must be commissioned separately?

Our support and billing policy provides transparency and reliability in this regard.

Key terms explained simply

Base software (standard/core)

The generally available SaaS standard software operated by crm-now, including all standard functions, modules, and interfaces, either in the productive version or in a provided demo environment.

Customizing

Customer-specific adaptations or extensions of the base software, for example:

• Individual workflows or business logic
• Customer-specific fields, forms, or data models
• Reports and dashboards
• Integrations with third-party systems
• Customer-specific code or scripts

Incident (service disruption)

An unplanned event in which the SaaS service is unavailable or only partially usable. An incident describes the operational impact, not necessarily the cause.

Bug (software defect)

A reproducible error in which the software deviates from the documented or contractually agreed expected behavior. A bug describes the technical cause.

Service request

A request for a service that does not constitute a disruption, for example:

• Configuration support
• User or role changes
• Assistance with usage or administration
• Commissioning of adaptations

Change request

A service request aimed at a substantive change or extension of the existing target state, such as new functions or modified processes.

Which services are free of charge?

Bug fixes in the base software

We correct reproducible errors in the base software free of charge as part of ongoing SaaS operations, provided that:

• The behavior deviates from the documented or contractually agreed expected behavior, and
• The error can be reproduced without customer-specific adaptations.

The correction is carried out via patches, hotfixes, or regular releases, possibly supplemented by a workaround.

Platform and operational disruptions

We also resolve disruptions within the responsibility of crm-now free of charge, for example:

• Availability issues
• Security-relevant defects in the base software
• Infrastructure or operational issues of the platform

Which services are subject to charges?

Chargeable services include in particular services provided individually for a customer:

Bug fixing related to customizations

Analysis and correction of errors whose cause lies in customer-specific adaptations or configurations.

Change requests and further development

All changes or extensions to the existing functional scope, for example:

• New functions or processes
• Adjustments to existing logic
• New reports, interfaces, or automations
• Performance optimizations, provided the base software operates in accordance with the contract

Support for external or customer-side causes

Analysis and support for issues caused, for example, by:

• Misconfigurations or data on the customer side
• Third-party systems or external interfaces
• Customer-side infrastructure

These services are billed at the agreed hourly rate or on the basis of a separate quotation.

The free initial diagnosis – fair and transparent

To enable a clear distinction, we first perform a free initial diagnosis for every request.

What does the initial diagnosis include?

• Review of your request and the information provided
• Verification of reproducibility in a standard environment
• Basic technical classification of the cause

The initial diagnosis is limited to up to 30 minutes per ticket and serves exclusively for classification, not for full resolution.

What happens next?

After completing the initial diagnosis, we inform you about:

• The classification of your request (base software bug, customization bug, service request, or change request)
• The recommended next steps
• If applicable, an effort estimate or a quotation

Chargeable services commence only after your approval. If a chargeable cause only becomes apparent during the initial diagnosis, billing starts only from the point at which we inform you accordingly.

Our classification principle

Decisive for the classification of a request are:

• The documented or contractually agreed expected behavior, and
• The technical cause.

An incident may be caused by a bug, but it does not have to be. A change request always constitutes a chargeable change in services unless otherwise agreed.

Conclusion

This policy creates transparency, planning certainty, and fair cooperation. You always know when support is part of SaaS operations and when it constitutes an individually commissioned service.

If you have any questions about this policy or the classification of your request, please feel free to contact us at any time.

Note: This explanation is provided for better understanding. The binding provisions are the respective valid support and billing policy as incorporated into the contractual documents (AGB, MSA, support terms, service descriptions).

1. Purpose and Overview

This extension provides a webservice function to retrieve all related records (relations) for one or more CRM records in vTiger / berliCRM.

Key characteristics:

• Supports multiple parent records in one call.
• Can optionally restrict results to a specific related module (e.g. only Contacts, only Documents).
• Respects user permissions (profiles, sharing, field permissions):
  • Only returns records that are accessible for the webservice user.
• Uses the same relation definitions as the normal vTiger UI, based on vtiger_relatedlists.

Typical use cases:

• Client portals or external integrations that need:
  • All related Contacts, Documents, Trouble Tickets, etc. for a given record.
  • Relations for multiple records in a single request, reducing round-trips.
• Batch synchronization of relations into external systems.

2. Function Signature

function berli_get_new_multi_relations($id, $relModule = 'all', $user)

Parameters

1. $id (string, JSON-encoded)
   • JSON string representing either:
     • a single webservice ID (“11×123”), or
     • an array of webservice IDs ([“11×123″,”11×456”]).
   • Each ID must be a webservice ID, not a plain CRM ID:
     • Format: <entityIdPrefix>x<crmId>Example: 11×123 where 11 is the entity ID and 123 is the CRM record ID.

   Internally:

$id = json_decode($id);
if (!is_array($id)) {
    $id = array($id);
}

1. So the function always works with an array of IDs.
2. $relModule (string, optional)
   • Default: ‘all’
   • Controls which related modules to include:
     • ‘all’Return relations for all related modules defined in vtiger_relatedlists for the entity.
     • <ModuleName> (e.g. ‘Contacts’, ‘Documents’)Return only relations where the related module matches this module.

   If the parameter is empty or omitted, it is normalized to ‘all’.

3. $user (User object)
   • The current Vtiger/berliCRM webservice user object.
   • Used to:
     • Initialize webservice handlers.
     • Check access rights (hasReadAccess, hasPermission).
     • Filter out entities the user is not allowed to access.

3. Return Value

array(
    "<parentWsId>" => array(
        "<RelatedModuleName>" => array(
            "<RelationLabel>" => array(
                "<relatedWsId1>",
                "<relatedWsId2>",
                ...
            ),
            ...
        ),
        ...
    ),
    ...
)

More explicitly:

• Top level key: parent record webservice ID (e.g. “11×123”).
• Second level key: related module name (e.g. Contacts, Documents).
• Third level key: relation label as defined in vtiger_relatedlists.label (decoded from HTML entities).
  • Example: “Contacts”, “Documents”, “Trouble Tickets”, or a custom label.
• Value: an array of related record webservice IDs belonging to that relation.

Example (simplified):

array(
    "11x123" => array(
        "Contacts" => array(
            "Contacts" => array("12x5", "12x7")
        ),
        "Documents" => array(
            "Documents" => array("14x20", "14x21")
        )
    ),
    "11x456" => array(
        "Contacts" => array(
            "Contacts" => array("12x8")
        )
    )
);

Notes:

• Each related record is returned only once per parent+module+relation label (duplicates are filtered).
• If a parent record has no accessible relations for a module/label, that section may be present but empty.

4. Permission and Security Handling

The function strictly respects vTiger/berliCRM’s permission system:

1. Entity type accessFor each parent ID:

$webserviceObject = VtigerWebserviceObject::fromId($db, $id);
$handler = new $handlerClass($webserviceObject, $user, $db, $log);
$meta = $handler->getMeta();
$entityName = $meta->getObjectEntityName($id);
$types = vtws_listtypes(null, $user);

if (!in_array($entityName, $types['types'])) {
    throw new WebServiceException(
        WebServiceErrorCode::$ACCESSDENIED,
        "Permission to perform the operation is denied"
    );
}

1. If the user has no access to the module of the parent record, a WebServiceException with ACCESSDENIED is thrown.
2. Record-level access
   • Checks if the record exists and is readable:

if ($meta->hasReadAccess() === false) { ... }
if (!$meta->hasPermission(EntityMeta::$RETRIEVE, $id)) { ... }
if (!$meta->exists($idComponents[1])) { ... }

2. • If these checks fail, the function throws:
     • ACCESSDENIED when the user cannot read the record.
     • RECORDNOTFOUND when the CRM ID does not exist.
3. Related module accessFor each related module:

$tmpWebserviceObject = VtigerWebserviceObject::fromName($db, $relatedModuleName);
$tmpHandler = new $handlerClass($tmpWebserviceObject, $user, $db, $log);
$tmpMeta = $tmpHandler->getMeta();

if ($tmpMeta->hasReadAccess() === true) {
    // execute relation query
}

3. This ensures:
   • Relations are only fetched for related modules the user can access.
   • Each related record is checked with hasPermission(EntityMeta::$RETRIEVE, $relCrmId) before being added to the result.
4. DeduplicationFor each relation query, the function tracks already added IDs:

$alreadySet = array();
while ($row2 = $db->fetch_row($res2)) {
    $relCrmId = $prefix.'x'.$row2['crmid'];
    if ($tmpMeta->hasPermission(EntityMeta::$RETRIEVE, $relCrmId) && !isset($alreadySet[$relCrmId])) {
        $arrRet[$id][$relatedModuleName][$label][] = $relCrmId;
        $alreadySet[$relCrmId] = $relCrmId;
    }
}

4. This prevents duplicate related IDs in the response.

5. Relation Discovery Logic

For each parent record:

1. Set current module

global $currentModule;
$currentModule = $entityName;

1. This is necessary for some internal vTiger APIs that depend on $currentModule.
2. Fetch relation definitionsThe function reads the relation definitions from vtiger_relatedlists combined with vtiger_tab:

$query = "SELECT * FROM vtiger_relatedlists
          INNER JOIN vtiger_tab ON vtiger_tab.tabid = vtiger_relatedlists.related_tabid
          WHERE vtiger_relatedlists.tabid = ? AND vtiger_tab.presence IN (0,2)";
$params[] = getTabid($entityName);

if ($relModule != 'all') {
    $query .= " AND related_tabid = ?";
    $params[] = getTabid($relModule);
}

$res = $db->pquery($query, array($params));

2. • tabid = module of the parent record.
   • related_tabid optionally limited to the module specified by $relModule.
   • presence IN (0,2) ensures only active or selectively visible modules are considered.
3. Generate actual relation queriesFor each relation row:

$label = html_entity_decode($row['label']);
$relatedTabid = $row['related_tabid'];
$relatedModuleName = Vtiger_Functions::getModuleName($relatedTabid);

$parentRecordModel = Vtiger_Record_Model::getInstanceById($idComponents[1], $entityName);
$relationListView = Vtiger_RelationListView_Model::getInstance(
    $parentRecordModel,
    $relatedModuleName,
    $label
);
$query = trim($relationListView->getRelationQuery());

3. • Vtiger_RelationListView_Model is used to build the same SQL query as used by the UI relation tabs.
   • The generated query is executed if not empty.
4. Execute relation queries

$res2 = $db->pquery($query, array());

4. Each result row is expected to contain at least crmid of the related record.

6. Error Handling

The function can throw WebServiceException in the following situations:

• Invalid module access for parentWebServiceErrorCode::$ACCESSDENIEDWhen the user has no access to the module of the parent record.
• No read access or missing record
  • ACCESSDENIED if user cannot read the specific record.
  • RECORDNOTFOUND if the CRM ID does not exist.
• SQL errors
  • On the relation definition query:

if (!$res) {
    throw new WebServiceException(
        WebServiceErrorCode::$QUERYSYNTAX,
        "Error with query: $query, parameter:".serialize($params)
    );
}

• • • On the relation records query:

if (!$res2) {
    throw new WebServiceException(
        WebServiceErrorCode::$QUERYSYNTAX,
        "Error with query2: $query"
    );
}

Client code consuming this webservice should be prepared to handle these exceptions.

7. Example Usage (Conceptual)

Webservice Call

Assuming the operation name is mapped to this function (for example getNewMultiRelations), a typical REST call could look like:

• GET or POST parameters:

operation=get_new_multi_relations
sessionName=<validSession>
id=["11x123","11x456"]
relModule=Contacts

• Response (simplified JSON):

{
  "success": true,
  "result": {
    "11x123": {
      "Contacts": {
        "Contacts": ["12x5", "12x7"]
      }
    },
    "11x456": {
      "Contacts": {
        "Contacts": ["12x8"]
      }
    }
  }
}

Note: The actual operation name and registration must match how you configured this function in vtiger_ws_operation and vtiger_ws_operation_parameters.

8. Performance Considerations

• The function loops over all passed IDs and, for each:
  • Reads relation definitions from vtiger_relatedlists.
  • Executes one relation query per relation definition.
• set_time_limit(0); is called in each outer loop iteration to avoid script timeouts for large data sets.

Recommendations:

• Avoid passing extremely large ID lists in one call.
• If you expect many relations per record, consider batching calls (e.g. 50–100 IDs per request).

9. Integration Notes

• Place getNewMultiRelations.php in a location accessible by your vTiger/berliCRM webservice environment.
• Register the function via the standard vtiger webservice configuration:
  • Add an entry in vtiger_ws_operation.
  • Add parameters (id, relModule) in vtiger_ws_operation_parameters.
  • Map the operation to the PHP function berli_get_new_multi_relations.

(Exact SQL or API calls for registration depend on your existing customization style.)