# Export vPlan **Category:** ERP **Version:** 1.0 **Last updated:** November 5, 2025 **Author:** Any2Info *** ### Description The **Export vPlan Node** provides a direct and user-friendly way to send data from the Any2Info DataHub to the vPlan API. It connects to all available **vPlan API endpoints**, including orders, activities, boards, resources, statuses, and custom entities. This makes it possible to create, update, or delete almost any type of data stored in vPlan directly from within the Any2Info DataHub. The node is continuously maintained to ensure compatibility with new and updated vPlan API endpoints. Whenever vPlan releases new functionality, the Any2Info integration is reviewed and updated accordingly. *** ### Property Options | Setting | Type | Required | Description | | -------------------- | -------- | -------- | -------------------------------------------------------------------------------------------- | | **Connection** | Select | No | (Optional) Select an existing connector, such as an OAuth 2.0 or API key-based connection. | | **Advanced** | Button | Yes | Opens the configuration window for entity mappings, operations, fields, and output behavior. | | **Entity library** | Select | Yes | Defines which version of the entity model to use (e.g., *Legacy* or *Latest*). | | **Preload Entities** | Checkbox | No | More information below | | **Update Policy** | Select | No | More information below | #### Preload Entities The **Preload Entities** option determines how existing records are retrieved when the node needs to perform operations such as CreateOrUpdate. When this option is **enabled**, the system retrieves existing entities in advance, before processing the input data. These entities are fetched in pages and cached for reuse during execution. This approach is particularly beneficial when processing multiple input rows. Without preloading, the system must perform a separate API call for each input record to check whether the entity already exists (for example, before updating it). While this is acceptable for a small number of records, it can result in a significant number of API calls when handling larger datasets. By enabling **Preload Entities**, the node reduces the number of required API calls by fetching entities in batches. Although this may initially require multiple paged requests, it is generally more efficient overall when working with many input records. Additionally, the preloading process is optimized to stop retrieving further pages as soon as all required entities have been found. This ensures that unnecessary data is not fetched, even when working with large datasets. **Summary:** * Disabled → One API call per input record * Enabled → Entities are fetched in bulk (paged), reducing total API calls * Recommended for larger incoming datasets #### Update Policy The **Update Policy** property defines how the node determines whether an update should be sent to vPlan. There are two available options: **Full (default)** When **Full** is selected, an update is always performed for each processed record, regardless of whether the data has actually changed. This means a **PUT API call** is sent to vPlan for every record, even if all mapped field values are identical to the existing entity. This option ensures data consistency but may result in unnecessary API calls. **Changes Only** When **Changes Only** is selected, the node first retrieves the existing entity from vPlan and compares it with the incoming data. Only the fields that are explicitly mapped in the node are included in this comparison. If at least one of these mapped fields contains a different value, an update is performed. If all compared values are identical, no update is sent. This approach reduces the number of API calls and improves performance, especially when processing large datasets with minimal changes. **Summary:** * **Full** → Always performs an update (PUT), regardless of changes * **Changes Only** → Updates only when mapped field values differ * **Changes Only** is recommended for performance optimization when many records remain unchanged *** ### Configuration Options | Setting | Type | Description | | ------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------- | | **Entity** | Select | Selects the vPlan entity type to export, such as *Card*, *Order*, *Collection*, *Project*, *Activity*, or *Resource*. | | **Operation** | Select | Defines the export action, such as *Create*, *Update*, *Update or Create*, or *Delete*, depending on the selected entity. | | **Output** | Tab | Displays the API response after the export operation. Useful for debugging and retrieving new IDs. | | **Column Mapping** | Table | Maps incoming DataHub fields to the corresponding vPlan API fields required for the selected entity and operation. | *** #### Supported Operations | Action | Description | | -------------------- | ------------------------------------------------------------------ | | **Create** | Creates a new record in vPlan. | | **Update** | Updates an existing record using its `id` or `external_ref`. | | **Update or Create** | Updates a record if it exists; otherwise creates it automatically. | | **Delete** | Deletes an existing entity in vPlan. | *** ### Tips & Best Practices * Validate incoming data (e.g., date formats, required fields) using a **Query** node before exporting. * Use **Update or Create** for system synchronizations to ensure stable incremental updates. * Keep `external_ref` stable and unique — this is the most reliable identifier for linking systems. * Filter out unchanged or duplicate data before exporting to prevent unnecessary updates. * When exporting large datasets, use batching or delays to prevent vPlan rate limits. * When using **Update Policy**, prefer *Changes Only* to minimize payload size and avoid overwriting unchanged fields. *** ### Errors & Troubleshooting | Error message | Meaning | Solution | | ----------------------- | ------------------------------------------------ | ------------------------------------------ | | **401 Unauthorized** | Invalid or expired API key. | Verify your connection configuration. | | **404 Not Found** | The specified entity or endpoint does not exist. | Check the entity name and library version. | | **400 Bad Request** | Invalid request payload or missing fields. | Validate mappings and required fields. | | **Rate Limit Exceeded** | Too many API requests. | Batch your export or reduce frequency. | *** ### Example Flow 1. **Time Trigger** The flow starts on a scheduled interval. 2. **Production Order Import (SQL)** Retrieves the latest production orders from the database. 3. **Compare Node (New or Changed Detection)** Compares current results with previously stored results. * **New**: orders that did not exist before. * **Changed**: orders with modified fields. 4. **Not Empty Check** Ensures only new or changed records continue. 5. **Export to vPlan** Only new or updated production orders are sent to the Export vPlan Node to be created or updated in vPlan.
*** ### Changelog | Version | Date | Change | | ------- | ----------------- | ------------------------------------ | | **1.0** | November 19, 2025 | Initial documentation version added. |