> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would… > Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. ## OpenAPI ````yaml /api-reference/openapi.json post /rpc/move_to_state_model openapi: 3.0.0 info: description: '' title: >- The only schema PostgREST exposes. Reads are security_invoker views; writes are SECURITY DEFINER functions. Rebuilt wholesale on every deploy — it holds no data. version: 12.2.3 servers: - url: https://app.assetinfinity.ai/api security: [] tags: - name: Signing in - name: Profile - name: My work - name: Sites and locations - name: Assets - name: Asset lifecycle - name: Asset components - name: Work lifecycle - name: Work order execution - name: Work sequencing - name: Maintenance - name: Inspections - name: Checklists - name: Verification - name: Self verification - name: Inventory - name: Inventory detail - name: Parts demand - name: Procurement - name: Vendors and contracts - name: Contracts - name: Amendments - name: Vendor spend forecast - name: Workforce - name: Workforce detail - name: Capacity - name: Dispatch - name: Shutdown - name: Permits - name: Tools - name: Tools on jobs - name: Bookings - name: Calibration history - name: Reliability - name: Sensors and meters - name: Readers - name: Trackers - name: Real-time location - name: Feeds - name: Energy - name: IT assets - name: IT asset software - name: IT asset topology - name: Map - name: Floor plans - name: Labels - name: Lost and found - name: Visitors - name: Root cause analysis - name: Costing - name: Finance - name: Budgets - name: Capex plans - name: FF&E plans - name: Documents - name: Document control - name: Document folders - name: Document tree - name: Knowledge - name: Reports - name: Dashboards - name: Extracts - name: Data exports - name: Audit center - name: Audit feed - name: Activity - name: Conversations - name: Notifications - name: Date reminders - name: Channels - name: Search - name: Copilot - name: Import - name: Bulk jobs - name: File exchange - name: Filing exceptions - name: Files - name: Sync - name: Support - name: API keys - name: Webhooks - name: MCP connections - name: MCP sign-in - name: SCIM provisioning - name: Directory sync - name: Security streams - name: Single sign-on - name: Two-factor sign-in - name: Admin - name: Access - name: Lookups - name: Read models - name: Reference - name: Reference columns - name: Reference entry - name: List views - name: Mapping - name: Numbering - name: Branding - name: Custom fields - name: Form studio - name: Workflows - name: Workflow studio - name: Rules - name: Statuses and transitions - name: Currencies and locales - name: Today - name: Work configuration - name: Asset configuration - name: Inventory configuration - name: Tool configuration - name: Workforce configuration - name: Vendor and contract configuration - name: Document configuration - name: Inspection configuration - name: Sites, locations and the organisation - name: Setup - name: Features - name: Billing - name: Licence - name: Welcome - name: Tray - name: Tenant switch - name: Release - name: Telegram - name: Inbound mail - name: Platform externalDocs: description: PostgREST Documentation url: https://postgrest.org/en/v12/references/api.html paths: /rpc/move_to_state_model: post: tags: - Statuses and transitions summary: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would… description: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. parameters: - $ref: '#/components/parameters/preferParams' requestBody: content: application/json: schema: description: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. properties: p_business_unit_id: format: uuid type: string p_dry_run: format: boolean type: boolean p_from_state_model_id: format: uuid type: string p_mapping: format: jsonb p_reason: format: text type: string p_site_id: format: uuid type: string p_to_state_model_id: format: uuid type: string p_type_id: format: uuid type: string required: - p_from_state_model_id - p_to_state_model_id type: object application/vnd.pgrst.object+json: schema: description: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. properties: p_business_unit_id: format: uuid type: string p_dry_run: format: boolean type: boolean p_from_state_model_id: format: uuid type: string p_mapping: format: jsonb p_reason: format: text type: string p_site_id: format: uuid type: string p_to_state_model_id: format: uuid type: string p_type_id: format: uuid type: string required: - p_from_state_model_id - p_to_state_model_id type: object application/vnd.pgrst.object+json;nulls=stripped: schema: description: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. properties: p_business_unit_id: format: uuid type: string p_dry_run: format: boolean type: boolean p_from_state_model_id: format: uuid type: string p_mapping: format: jsonb p_reason: format: text type: string p_site_id: format: uuid type: string p_to_state_model_id: format: uuid type: string p_type_id: format: uuid type: string required: - p_from_state_model_id - p_to_state_model_id type: object text/csv: schema: description: >- Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together. `p_type_id` is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. `p_mapping` names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with `p_dry_run` false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in. properties: p_business_unit_id: format: uuid type: string p_dry_run: format: boolean type: boolean p_from_state_model_id: format: uuid type: string p_mapping: format: jsonb p_reason: format: text type: string p_site_id: format: uuid type: string p_to_state_model_id: format: uuid type: string p_type_id: format: uuid type: string required: - p_from_state_model_id - p_to_state_model_id type: object required: true responses: '200': description: OK components: parameters: preferParams: description: Preference in: header name: Prefer required: false schema: enum: - params=single-object type: string ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.