インストールしたパッケージをカスタマイズする上でハマったこと
Force.com上で開発していく上で、パッケージをカスタマイズしていくことも多々あるのではないでしょうか？
（当方、glovia OrderManagementをカスタマイズすることが多いですが...）
そんなパッケージのカスタマイズの中で、思わぬ出来事に遭遇しましたのでご紹介しようかと。
結論から先に言うと...
ということです。
※予期せぬ例外が発生することもあるので避けるべき、ということです。
具体例
準備
今回発生したケースの前提です。
- パッケージ管理内で、「Status__c」というAPI名がテキスト型として定義されている（実際には、xxx__Status__c というAPI名になります）
- 上記のオブジェクトにカスタム項目として「Status__c」を選択リスト型として追加する
パッケージ内のオブジェクトとしては、こんな項目が定義されたようになります。
- xxx__Status__c（テキスト型）
- Status__c（選択リスト型）
ここで、さらに入力規則 or 項目自動更新で、「Status__c」を数式に使ってみます。例えば
IF( TEXT ( Status__c ) = 'xxxx', 100, 0);
という感じの数式を埋め込んでみます。
※ココでは、新たに追加した選択リスト型のStatus__cを使う感じです。
例外発生！
項目自動更新が実行されると、こんなエラーが発生するようになりました。
このレコードを保存するとき、ワークフローまたは承認プロセスの項目自動更新によるエラーが発生しました。（中略）
関数 'TEXT()' のパラメータが間違っています。期待数字, 日付, DateTime, 選択リスト、受信テキスト
え？
関数 TEXT() は選択リスト型で使用しているのに、なぜこんなエラーがッ...！？
大まかに書くと、こんな感じの現象でしょうか。。
原因は？
管理パッケージ内のトリガが起動したとき、それに併せて入力規則（パッケージ管理外で定義された入力規則も含めて）が評価されると思います。
入力規則を評価する際に、パッケージ内のトリガで発生してきた場合にはパッケージ内の項目を優先的に参照するのではないでしょうか？
（ただ、標準のSalesforce画面からデータ操作した場合、エラーなく処理されることもあったりと良く分からない・・ところもあります。すみません。。。）
回避策は？
結局のところ、
パッケージ内で定義されているAPI名で項目を追加するのは避けましょう
に尽きると思います。
今回の例でいうと、
- パッケージ内では Status__c（テキスト）で定義されている。（外部からは xxx__Status__c）
- パッケージ外で Status__c（選択リスト）で定義する
ということは止めましょう、という話ですね。
ただ、上記の現象とは別に、類似した名称で定義するのは混乱の火種になりかねないので、名前付けは熟考しましょう、ということですね。
※当たり前すぎる話でオチもないですが・・（苦笑）
最後に
一応、Salesforceに問い合わせたところ、既知の不具合のようで将来的なリリースにて修正予定とのことでした。（時期は未定）
そんなわけで、しばらくは
類似したAPI名を使うのは避ける
という回避策で逃げましょう。
今回はパッケージをカスタマイズしていく上でハマったお話でした。
ではでは〜
