- 概要
- はじめに
- 概念
- UiPath CLI を使用する
- 使用ガイド
- CI/CD レシピ
- コマンド リファレンス
- 概要
- 終了コード
- グローバル オプション
- uip codedagent
- uip coder
- uip context-grounding
- uip docsai
- uip function
- uip guardrails
- uip llm-configuration
- uip llm-gateway
- uip model-hub
- add-test-data-entity
- テスト データのキューを追加
- 追加-テスト-データ-バリエーション
- 分析
- 開発
- プロジェクトを作成
- 差分
- アクティビティを検索
- GET-ANALYZER-RULES
- get-default-activity-xaml
- エラーを取得
- 手動テスト用のテスト ケースを取得
- 手動テストステップを取得
- get-library-object-repository
- get-object-repository
- get-versions
- Get-workflow-example
- indicate-application
- 要素を示す
- inspect-package
- install-data-fabric-entities
- パッケージのインストールまたは更新
- list-data-fabric-entities
- list-instances
- list-workflow-examples
- パッケージ化
- パブリッシュ
- remote
- 元に戻す
- run, debug & execution
- ファイル名を実行
- 検索テンプレート
- スタートスタジオ
- 実行を停止
- tm
- UIA
- uip tasks
- uip traces
- uip traces feedback
- 移行
- 参照とサポート
Syntax and options for `uip insights filter-processes`, which discovers processes with recent Insights activity for use with --process-name filters.
uip insights filter-processes discovers processes that have had Insights activity recently, restricted to folders the current caller can access. Use it to find the --process-name values that jobs accepts.
"Recent" is a fixed 30-day window set by the backend — it cannot be changed with a flag. This route is also feature-gated to Cloud and Dedicated SaaS deployments; on other deployment types the command fails with a ConfigError rather than an empty result.
概要
uip insights filter-processes list [-l <n>] [-o <n>]
uip insights filter-processes list [-l <n>] [-o <n>]
This verb honors the global options and the standard exit codes. It does not accept -t, --tenant — it uses the tenant selected during uip login.
uip insights filter-processes list
List processes with Insights activity in the backend's fixed 30-day window.
オプション
| フラグ | 説明 |
|---|---|
-l, --limit <number> | Maximum rows to return. Defaults to 50. |
-o, --offset <number> | Rows to skip before returning results. |
Rows are deduplicated and sorted after fetching — the backend returns one entry per underlying job run, not one per distinct process, so pagination is over the distinct set. Pagination itself is client-side, over the full unpaginated backend response.
例
uip insights filter-processes list
uip insights filter-processes list
データシェイプ
{
"Code": "InsightsFilterProcessesList",
"Data": [
{
"processName": "Invoicing",
"folderKey": "f0f0f0f0-0000-0000-0000-000000000001"
}
],
"Pagination": { "Returned": 1, "Limit": 50, "Offset": 0, "Total": 1, "HasMore": false }
}
{
"Code": "InsightsFilterProcessesList",
"Data": [
{
"processName": "Invoicing",
"folderKey": "f0f0f0f0-0000-0000-0000-000000000001"
}
],
"Pagination": { "Returned": 1, "Limit": 50, "Offset": 0, "Total": 1, "HasMore": false }
}
The backend also returns process key, version, and project key data, but only processName and folderKey are guaranteed aligned across rows and are emitted — the other fields skip null entries in the backend response and can lose row alignment, so they're deliberately not included. An empty Data array means no matching activity in the 30-day window — it is not proof the process doesn't exist.
関連
- jobs — accepts
--process-namevalues discovered here. - filter-folders, filter-machines, filter-queues — sibling discovery commands.