Actions54
- Resource Actions
- Userpermissions Actions
- Baselinefile Actions
- Locks Actions
- Briefcases Actions
- Checkpoint Actions
- Thumbnail Actions
- Extendeddata Actions
- Changesets Actions
- Changesetgroups Actions
- Permissions Actions
- Recents Actions
- Namedversions Actions
- Shares Actions
- Rolepermissions Actions
- Users Actions
- Favorites Actions
- Fork Actions
- Clone Actions
- Create Actions
Overview
This node interacts with the iTwin Platform to create a fork of an existing iModel. Forking an iModel allows users to create a new iModel based on an existing one, optionally including its changeset history or just the baseline. This is useful in scenarios where you want to branch off an existing digital twin model for parallel development, experimentation, or versioning without affecting the original.
Practical examples include:
- Creating a sandbox environment from a production iModel to test changes.
- Branching an iModel for different project phases or teams.
- Archiving a snapshot of an iModel at a certain changeset state.
Properties
| Name | Meaning |
|---|---|
| ID | The unique identifier of the iModel to be forked. |
| iTwin ID | The identifier of the iTwin within which the new iModel fork will be created. |
| Changeset ID | The ID of the latest main iModel changeset to copy into the fork. If not provided, all changesets are copied. If set to an empty string, no changesets are copied and only the baseline is used. |
| Changeset Index | Alternative to Changeset ID; specifies the index of the latest changeset to copy. If not provided, all changesets are copied. If set to 0, no changesets are copied and only the baseline is used. Must be a non-negative integer. |
| Name | The name of the new iModel fork. If omitted, the original iModel's name is used. Must be unique within the iTwin and up to 255 characters. |
| Description | A description for the new iModel fork. If omitted, the original iModel's description is used. Up to 255 characters. |
| Preserve History | Boolean flag controlling how changesets are copied: true copies changesets individually preserving history; false squashes changesets into the baseline resulting in no changeset history. Defaults to false. |
| Options | Collection allowing to specify a custom JSON payload to override the default request body sent to the API. Useful for advanced use cases requiring direct control over the API request. |
Output
The node outputs JSON data representing the newly created iModel fork. The structure typically includes details about the forked iModel such as its ID, name, description, and metadata returned by the iTwin Platform API.
No binary data output is indicated.
Dependencies
- Requires an API authentication credential (OAuth2 token) configured for the iTwin Platform.
- Depends on the iTwin Platform APIs for iModel management.
- The node internally uses an OpenAPI interpreter module to execute operations against the iTwin API.
Troubleshooting
Common issues:
- Providing an invalid or non-existent iModel ID or iTwin ID will cause errors.
- Specifying a duplicate name for the new iModel fork within the same iTwin will fail due to uniqueness constraints.
- Incorrect changeset IDs or indexes may result in failure or unexpected behavior.
- Omitting required parameters like
IDoriTwin IDwill cause validation errors.
Error messages:
"Unknown operation": Indicates the specified operation is not supported; ensure "Fork iModel" is selected.- API errors related to authorization: Check that the API key or OAuth2 credentials are valid and have sufficient permissions.
- Validation errors on input properties: Verify that all required fields are correctly filled and conform to expected formats.