プロセス定義の各要素は、名前を持ちます。命名に関する唯一の規則は、Java 言語キーワードを使用できないことと、同じプロセス図内に同名の要素を２つ以上使用できないことです。 たとえば、１つのプロセス図内に２つの beanCounter と呼ぶ変数を持つことはできません。それらが別々のプールにあったとしてもです。ただし、 beanCounter と呼ぶ変数と beanCounter と呼ぶアクターをもつことは可能です。

注意： 変数は、Studio と UI デザイナー間で共有できません。しかも、UI デザイナー内ではページ間でも変数は共有できません。UI デザイナー内の変数の使用に関する詳しい情報は「変数」を参照してください。

比較的単純なプロセスでも、名前の数はすぐに多くなります。戦略的な命名方針を決めておくことは、プロセスの可読性と保守性を高め、要素の再利用が容易になります。Bonitasoft は、次の「ベストプラクティス」を提案します。

• 意味が分かる名前を付けることです。この目的は、コードをあえて解読しなくても何をするのか分かるようにすることです。短い名前よりも長く、意味が分かる名前の方がベターです。大抵の場合、名前は１度だけタイプインする必要がありますが、その後はリストから選択できます。したがって、短い名前を使用するメリットはありません。たとえば、ブールアンの変数名は、「領収書」より true の状態を意味する「申告された領収書がある」の方がベターです。
• 名前は、「何のことなのか」、あるいは「それは何をするのか」を示すことができます。変数に対しては、「それはどんなものか」、「すなわち、～のこと」、「それは何をストアしているのか」を示すことがさらに有益です。
• プロセス内部、および複数のプロセス間でも再利用やコピーを活用し整合性を持たせることです。再利用やコピーしたい要素を探し出すことが簡単なら、再利用の可能性は高くなります。
• プール名は高位のビジネスプロセス名を使って命名することです。ビジネスプロセスにいくつかのプールがある場合、それらのプールがどのように関係しているかを告げる名前を使用します。たとえば、休暇申請がメインプロセスおよび休暇申請のレビューのためにコールされるプロセス（サブプロセス）とエスカレーションのためにコールされるプロセス（サブプロセス）を持っている場合、それらのプールを「休暇申請」、「休暇申請のレビュー」、「休暇申請のエスカレーション」と呼ぶことになります。
• レーンにはプロセスを遂行する人を示す名前を付けます。一般的には、アクター名を使用し、同じレーンには同じアクターでアクティブをグループ化すべきです。このさらなる利点はプロセス図中でアクターを見えるようにすることです。
• タスクは「何をするか」（つまり動詞を使う）を明確に示すように名前を付けます。これはヒューマンタスクのみならず、すべてのタスク タイプにとって重要です。
• 可用性および保守性のためには、すべてのタスク名に同じ文法表現（対象[A]＋動詞｛B｝、 「AをBする」あるいは「AのB」）を適用し、統一した動詞句を用います（この場合、レーン名に記されたアクター名が主語になります）。休暇申請プロセスの例にとると、それらのタスクを「マネージャが申請をレビューする」や「人事がレビューする」とは呼びません。前者は主語が余計、後者は対象が不明です。
• ゲートウェイには、「判定する事」を名前に付けます。
• ゲートウェイから流出するシーケンスフローのすべてに「判定で下される結果」を名前として付けます（パラレル ゲートウェイからの流出シーケンスフローは除く）。
• 終了イベントの名前は、「終了した状態」、できれば「その理由」を示すべきでしょう。いくつかのフローを持つプロセスでは、それぞれのフローがどのような状態で終了するのか知る必要があります。たとえば、「休暇申請のマネージャレビュー終了」や「休暇申請の承認却下終了」などの例です。
• 変数は、プロセスデータとタスクデータの間で違いを付けます。たとえば、すべてのプロセスデータ名に「p_」、すべてのタスクデータ名に「t_」、の接頭辞を付けて識別できるようにします。
• 変数とパラメータは、その名前の中でデータ型を暗黙的に示すようにします。これは、 プーリアン型に対しては is や has を、その他の型では date, price, number などの用語をそれとなく使用し行います。たとえば、p_RecieptRequested は p_hasRequestedReceipt に、 p_FirstLeaveDay は p_dateOfFirstLeaveDay に、 p_DaysRequested は p_numberOfDaysRequested に、 p_TrainingFee は p_pricePerDayOfTraining に変えます。また、データ型をそれとなく示すこともできます。たとえば、 p_int_numberOfDaysRequested や p_date_StartOfLeave です。
• コネクタのインスタンスには、コネクタの種類ではなく、それが「何を行うのか」を示す説明的な名前を付けます。プロセスが同じコネクタをいくつかの箇所で異なるデータを取り扱う場合、これは特に重要になります。たとえば、社員のコンタクト先の詳細を更新するためのプロセスで、既存データの取得や更新テータの書き込みに PostgreSQL のコネクタを使用すると仮定した場合、そのコネクタのそれぞれのインスタンスには、 posrgresqlGetEmployeeContactInfo と postgresqlUpdateEmployeeContactInfo という名前を付けることが可能です。
• 式（Groovy スクリプトなど）には、その目的を示す説明的な名前を付けます。ビジネスプロセス内ではユニークな名前を使用します。
• 再利用可能な標準要素（たとえば、Groovy スクリプトやデータ型定義）のライブラリを作成済みの場合、その各標準要素は、明快に理解できる説明的な名前を付けます。たとえば、createOperations （日本語なら「操作を作成」）ではなく createOperationsListFromVariablesMap （日本語なら「変数マップから操作リストを作成」）です。再利用可能な標準要素をプロセス内にインポートし変更して利用する場合は、その変更済み要素の使用プロセスが特定可能で、かつそのリポジトリ内でユニークな新しい名前で保存します。この規則を適用するによって、これらの標準要素を個別改修する場合、標準要素を上書きしてしまう危険を回避できます。すなわち、標準要素を使用している既存のプロセスに問題を波及させないようにすることです。

あらかじめ決めた命名規約の使用に加え、プロセス内の各要素に説明を記述することによって、そのプロセスの保守性を改善できます。プロセス図上にテキスト注釈を使用することも可能ですが、あまり長いテキスト注釈は、逆にそのプロセス図を読みにくくします。したがって、テキスト注釈は主として、訂正または完遂すべき何かを一時的に書き留めるため、あるいはビジネスアナリストとアプリケーション開発者間のコミュニケーションのために使用することを推奨します。