Action On Component
Action on component performs START, STOP, or RESTART on a selected runtime component such as a source, connector, storage, audio device, or integration that can have dependent tasks and subscribers.
Control component lifecycle without host access
Use this action when Event Manager rules, schedules, manual controls, or action groups need to start, stop, or restart a reusable component. It is useful for connector recovery, controlled source shutdown, maintenance windows, privacy periods, and operator-facing restart buttons.
Stopping a component can affect dependent tasks and actions, so use it at the boundary where that wider impact is intended: a media source, file storage, email connector, portal integration, audio device, or discovery service.
Select the controlled component
Set Target component to the runtime component that should receive the lifecycle command.
Choose persistent or runtime control
Enable Affect autostart state when the action should change whether the component starts automatically after the agent restarts. Disable it for temporary runtime control.
Check dependent tasks
Before using Stop or Restart, check which tasks subscribe to the component. They can stop, fail to start, or wait until the component is running again.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Target component | Yes | Component that will receive the lifecycle command. | None |
Affect autostart state | Yes | When enabled, START and STOP update the saved autostart state and persist the target component configuration. RESTART does not change the saved autostart value. | Enabled |
Ignore auto-start state | Yes | For runtime START, allows the component to start even if its saved autostart flag is disabled. Relevant when Affect autostart state is disabled. | Disabled |
Action | Yes | Lifecycle command to perform: Start, Stop, or Restart. | None |
Control the component and its dependent subscribers
Stopping a component stops its subscribers first. Any tasks or actions that depend on it can stop, fail to start, or wait until the component is running again. Starting a component also attempts to start subscribers according to the same autostart handling.
With Affect autostart state enabled, START and STOP persist the saved autostart flag. With it disabled, lifecycle commands affect only the current runtime state and do not persist component configuration.
Source boundary
Use the action at source or connector level when all dependent processing should follow that component state.
Autostart control
Use START and STOP as persistent enable/disable switches when operating mode should survive agent restart.
Recovery restart
Restart stale network connectors, datasource connections, audio devices, discovery services, and other reusable integrations.
Component lifecycle scenarios for sources and integrations
Autostart state control
Persistent enable or disable
Keep Affect autostart state enabled when the action should change whether the component starts automatically after the agent restarts. Start starts the component and persists autostart on; Stop stops it and persists autostart off.
Temporary runtime stop
Disable Affect autostart state and use Stop when a rule should pause a connector, media source, storage, audio player, or integration only for the current runtime session. The saved autostart setting remains unchanged.
Temporary runtime start
Disable Affect autostart state, set Action to Start, and enable Ignore auto-start state when a component with autostart disabled should be started on demand without changing saved configuration.
Respect configured autostart
Disable both Affect autostart state and Ignore auto-start state when the action should start the component only if its own autostart flag already permits it.
Recovery and scheduling
Connector recovery
Use Restart for network-dependent components such as portal integration, email connector, datasource, discovery, audio, or camera-related sources when a connection becomes stale or dependent workflows report repeated errors.
Controlled source shutdown
Stop a source component when a rule, schedule, or operator decision should stop all dependent processing. This is useful for maintenance windows, privacy periods, low-power modes, or temporary isolation of a faulty device.
Manual maintenance action
Expose a safe restart button for operators who need to recover a connector or source without direct OS access or full configuration permissions.
Scheduled availability
Combine this action with schedule rules when a component should run only during known operating hours, for example a discovery service, optional connector, or expensive external integration.
Operational notes
Stopping affects subscribers
Stopping a component stops its subscribers first. Dependent tasks or actions can stop, fail to start, or wait until the component is running again.
Starting can bring children online
Starting a component also attempts to start subscribers according to the same autostart handling. This can bring dependent tasks back online together with the source.
Persistent mode changes autostart
With Affect autostart state enabled, START and STOP use engine-level operations and persist the changed autostart flag. RESTART restarts the component but does not change its saved autostart value.
Runtime mode does not persist
With Affect autostart state disabled, START, STOP, and RESTART operate only on the current runtime state and do not persist component configuration.
Ignore auto-start only affects runtime start
Ignore auto-start state matters for runtime START. If disabled, a component with autostart off can refuse to start; if enabled, it starts for the current session.
No custom restart delay
This action has no configurable restart delay. The underlying component restart flow uses its default short delay before starting again.
System components may be protected
Persistent STOP can be unavailable for singleton or system components. Use it mainly for normal configurable components where stopping is an expected operation.
Terminal in task pipelines
When used inside a task pipeline, the action stops downstream processing after controlling the target component. Place it as a terminal control action unless stopping downstream processing is intentional.
Avoid restart loops
Avoid rules where a component restart immediately triggers another event that restarts the same component again. Add cooldowns, schedules, or Event Manager conditions around recovery rules.
Deleted targets require reconfiguration
If the selected component is deleted or unavailable, initialization fails and the action must be reconfigured with a valid target.