Lightning ExperienceではChatterグループのページにエンゲージメントタブが用意されています。こちらの機能をつかってグループの活動情報を表示できます。
投稿数や質問数、未回答のままの質問の件数まで確認することができます。
グループのページで確認できるので便利な機能だと思います。
Lightning ExperienceではChatterグループのページにエンゲージメントタブが用意されています。こちらの機能をつかってグループの活動情報を表示できます。
投稿数や質問数、未回答のままの質問の件数まで確認することができます。
グループのページで確認できるので便利な機能だと思います。
Spring'17からLightning ExperienceにChatterグループのカスタマイズ機能が追加されました。
他のページと同じようにLightning App Builderをつかってカスタマイズできます。Lightningコンポーネントを用意すれば自由に機能拡張を行えそうです。
Lightning Design SystemのProgress Indicatorを試してみました。普段画像などを用意して実装するプログレスバーをCSSとSVGで表現することができます。
バージョン2.1では正しく動作しなかったので現時点で最新の2.2.1で試してみました。
Lightning Design SystemのサイトにあるサンプルコードをVisualforceページで動かすと一つ目のマーカーの左側にスペースができてしまいます。
これはCSSでマージンを変更することで解決します。
ol li { margin-left: 0; }
※実際には他のCSSに干渉しないようにクラスやID指定を組み合わせます。
Progress Indicatorで各マーカーの下にラベルを表示したいときがあると思います。その場合はslds-is-relativeをつかって対応可能です。
モバイルレイアウトでも対応してくれる便利なCSSコンポーネントでした。
Spring'17で正式リリースされたStub APIを試してみました。Apexテストで例外テストができる仕組みを用意できたりするみたいです。
リリースノートだけではイマイチ使い方がわかりませんでしたが、Apex開発者ガイドでサンプルコードが紹介されていました。
まずテスト対象のクラスとして下記処理を用意します。
public class DateFormatter { // Method to test public String getFormattedDate(DateHelper helper) { return 'Today\'s date is ' + helper.getTodaysDate(); } }
次のヘルパークラスに処理部分をもたせます。
public class DateHelper { // Method to stub public String getTodaysDate() { return Date.today().format(); } }
上記処理は以下のような書き方で呼び出すことができます。
DateFormatter df = new DateFormatter(); DateHelper dh = new DateHelper(); String dateStr = df.getFormattedDate(dh);
このように独立させた処理をスタブAPIをつかって効率よくテストできるみたいです。
試験のために、私たちは隔離したいです getFormattedDate()この方法は、フォーマットが正常に動作していることを確認します。の戻り値getTodaysDate()この方法は、通常、日によって異なります。ただし、この場合には、我々は、フォーマットに私達のテストを分離するために一定の、予測可能な値を返すようにしたいです。むしろこの方法が一定の値を返すクラスの「偽」のバージョンを書くよりも、私たちは、クラスのスタブバージョンを作成します。スタブオブジェクトは、実行時に動的に作成され、私たちはその方法の「スタブ」動作を指定することができます。
Apexクラスのスタブバージョンを使用するには:
- 実装することで、スタブクラスの動作を定義します System.StubProvider インタフェース。
- 使用してスタブオブジェクトをインスタンス化します System.Test.createStub() 方法。
- テストクラス内からスタブオブジェクトの関連するメソッドを呼び出します。
StubProviderインターフェイスの実装します。implements System.StubProvider と宣言したテストクラスになります。
@isTest public class MockProvider implements System.StubProvider { public Object handleMethodCall(Object stubbedObject, String stubbedMethodName, Type returnType, List<Type> listOfParamTypes, List<String> listOfParamNames, List<Object> listOfArgs) { // The following debug statements show an example of logging // the invocation of a mocked method. // You can use the method name and return type to determine which method was called. System.debug('Name of stubbed method: ' + stubbedMethodName); System.debug('Return type of stubbed method: ' + returnType.getName()); // You can also use the parameter names and types to determine which method // was called. for (integer i =0; i < listOfParamNames.size(); i++) { System.debug('parameter name: ' + listOfParamNames.get(i)); System.debug(' parameter type: ' + listOfParamTypes.get(i).getName()); } // This shows the actual parameter values passed into the stubbed method at runtime. System.debug('number of parameters passed into the mocked call: ' + listOfArgs.size()); System.debug('parameter(s) sent into the mocked call: ' + listOfArgs); // This is a very simple mock provider that returns a hard-coded value // based on the return type of the invoked. if (returnType.getName() == 'String') return '8/8/2016'; else return null; } }
クラスのスタブバージョンをインスタンス化します。
public class MockUtil { private MockUtil(){} public static MockProvider getInstance() { return new MockProvider(); } public static Object createMock(Type typeToMock) { // Invoke the stub API and pass it our mock provider to create a // mock class of typeToMock. return Test.createStub(typeToMock, MockUtil.getInstance()); } }
これでテストクラスからスタブAPIを利用する準備ができました。次のようなテストの書き方ができます。
@isTest public class DateFormatterTest { @isTest public static void testGetFormattedDate() { // Create a mock version of the DateHelper class. DateHelper mockDH = (DateHelper)MockUtil.createMock(DateHelper.class); DateFormatter df = new DateFormatter(); // Use the mocked object in the test. System.assertEquals('Today\'s date is 8/8/2016', df.getFormattedDate(mockDH)); } }
無事開発者ガイドのサンプルコードのテストを実行することができました。
開発者ガイドのサンプルでは任意のシステム日付をセットしてテスト実行できることを確認できます。DateHelperクラスの処理でDate.todayでシステム日付を取得しています。MockProviderクラスの30行目でテストデータ用に任意の値で疑似システム日付を準備していました。DateFormatterTestクラスの12行目でスタブAPIをつかって用意した疑似システム日付がただしく利用できていることをassert処理で確認しています。
StubProviderインターフェイスの実装は少しややこしそうですが、疑似システム日付を用意できるのはすごく便利そうです。また、疑似Exceptionなども実装することができればテストがやりやすくなると思います。
Spring'17 へのアップデートで新しい一括処理ジョブページが利用できるようになりました。
設定のApexジョブのページに行くとリンクが追加されています。
こちらが新しいジョブページです。
特定の一括処理クラスで [詳細情報] をクリックすると、次の情報を含む一括処理クラスの親ジョブが表示されるそうです。
実行時に表示された内容です。
詳細リンクをクリックしたときの内容はこんな感じでした。
新しいジョブページはClassicとExperienceの両方で利用可能とのことです。
Salesforceは日本用のインスタンスでAP0が用意されています。災害発生などで長期間利用できない状態になった時にどのように対応されるかについてサクセスコミュニティで紹介されていました。
https://success.salesforce.com/0D53A00002wdabm
災害対策用の専用AP0インスタンスが別に用意されていてリアルタイムで同期を取っているそうです。
Salesforceは日本用のインスタンスでAP0が用意されています。災害発生などで長期間利用できない状態になった時にどのように対応されるかについてサクセスコミュニティで紹介されていました。災害対策用の専用AP0インスタンスが別に用意されていてリアルタイムで同期を取っているそうです。
こういった情報の詳細は下記にまとめられているとのことでした。
Lightning Experienceへの移行をする際にChatterメッセージが使えなくなるのが地味に障壁となっていました。Lightning ComponentでつくってあるChatterメッセージアプリがあれば解決するんだけどなと考えていたらそういうアプリを作ってくれている人が居たのを思い出しました。
README.mdにインストール方法も記載されています。
まずはgit cloneコマンドでソースコード一式をダウンロードします。
build-sample.propertiesをコピーしてbuild.propertiesを作成します。
DE組織あたりでパッケージを作成します。(たぶん。。)
lm.namespaceに作成したパッケージ名を入力。ユーザ名とパスワードにDE組織のログイン情報を入力します。
デプロイはantを利用します。Force.com移行ツールの出番です。
build.xmlは用意されています。後はコマンドを実行するだけです。
ant -Dpackage.xml=package.xml -f build.xml deploy
こんな感じ。
よくみるとエラーとなっていました。
Error: No COMPONENT named markup://LightningMessage:LightningMessageCmp found : [markup://c:LightningMessage]
やり方がよくなかったみたいです。ソースコードは取得できているので今回はgulp-jsforce-deployを使う方法で対応します。
git cloneしてソースコード一式取得した後にpkgフォルダにLightning Messageアプリのコードを格納します。
Set upに記載されているコマンドを実行して準備します。
デプロイコマンドはこんな感じ。
$ SF_USERNAME=username@example.com SF_PASSWORD=yourpassword gulp deploy
次のようなエラーがでたらnpm installでインストールすれば解決します。
Error: Cannot find module 'through2'
あとは次のエラーがでるかもしれません。
メインマークアップは空にできません。Lightning 定義バンドルを削除する場合は、代わりにバンドルを直接削除してください。
ソースコードで __namespace__と記述されている箇所があるのでc:とか除外とかすれば解決します。(antのときのエラーはこれが原因かな)
これでデプロイを実施できました。
試しにアプリケーションを開いてみると
どこか設定不足かもしれませんがエラーが。Lightning Componentの仕様は頻繁に変更されているのでそれが原因かもしれません。
antとかよくわからないまま試してみたのでどこか手順ミスがあったかもしれません。またエラーメッセージもちゃんと調べれば解決するかもしれないです。今回はそこまでやる予定はないのでここまで。Force.com移行ツールやgulp-jsforce-deployの使い方を久しぶりに思い出せて良かったです。
antをつかったインストールの正しい手順を確認できたので追記しました。
Part 1の続きです。
前回失敗してみてnamespaceの部分は管理パッケージの名前プレフィックスを付けるべきだったんじゃないかと気づきました。(当時Lightning Componentを開発するには名前プレフィックスが必須でした...)
ということでgit clone→build.propertiesファイル作成→パッケージ用名前プレフィックスを指定と対応します。
準備ができたらデプロイコマンドを実行します。
$ ant -Dpackage.xml=package.xml -f build.xml deploy
今回はあっさり成功しました。
開発者コンソールからソースコードを確認できます。
私のドメインの有効化は必須です。未対応の場合はエラーとなります。
アプリにアクセスするとエラーメッセージが表示されました。
ですがインストール手順は正しくできていると思いますので、ソースコードを現在の仕様に合わせて修正するだけで使えるようになるんじゃないかと思います。やり方がわかればすごくシンプルなインストール手順でした。
Community Cloudで顧客とChatterでやりとりする際に相手の投稿が通知されない問題に遭遇することがあると思います。例えば自分のユーザプロファイルに直接投稿してもらったり、メンションを指定してくれれば通知メールは届きますが、B2Cの顧客にそんなことをお願いするのは難しいと思います。
そこでApexトリガで対応するのはどうかと下記のトリガ処理をつくってみました。(サンプル処理なので本番向けではありません。)
trigger FeedItemTrigger on FeedItem (after insert) { private FeedItemTriggerHandler handler = new FeedItemTriggerHandler(); if (Trigger.isAfter) { if (Trigger.isInsert) { // コミュニティユーザがサポートフィードに投稿したことを担当者に通知 handler.notificationCustomerChatterPost(Trigger.new); } } }
public with sharing class FeedItemTriggerHandler { /** * コンストラクタ */ public FeedItemTriggerHandler() { } /** * コミュニティユーザがサポートフィードに投稿したことを担当者に通知 */ public void notificationCustomerChatterPost(List<FeedItem> feedItems) { // サポートフィードへの投稿を通知対象として取得 List<FeedItem> targetFeedItems = new List<FeedItem>(); for (FeedItem f : feedItems) { // オブジェクト判定 if (String.isNotEmpty(f.ParentId) && f.ParentId.getSObjectType().getDescribe().getName() == 'Support__c') { targetFeedItems.add(f); } } // Chatterに投稿 for (FeedItem f : targetFeedItems) { // new connect api ConnectApi.MentionSegmentInput mentionSegmentInput = new ConnectApi.MentionSegmentInput(); ConnectApi.FeedItemInput feedItemInput = new ConnectApi.FeedItemInput(); ConnectApi.MessageBodyInput messageBodyInput = new ConnectApi.MessageBodyInput(); ConnectApi.TextSegmentInput textSegmentInput = new ConnectApi.TextSegmentInput(); ConnectApi.FeedElementCapabilitiesInput feedElementCapabilitiesInput = new ConnectApi.FeedElementCapabilitiesInput(); // new List messageBodyInput.messageSegments = new List<ConnectApi.MessageSegmentInput>(); // Post Message String post = '【システム通知】新しいメッセージが投稿されました。'; // textSegment set textSegmentInput.text = post; messageBodyInput.messageSegments.add(textSegmentInput); // feedItem set feedItemInput.body = messageBodyInput; feedItemInput.feedElementType = ConnectApi.FeedElementType.FeedItem; // Use a group ID for the subject ID. feedItemInput.subjectId = '<TARGET_USER_ID>'; // capabilities feedElementCapabilitiesInput.link = new ConnectApi.LinkCapabilityInput(); feedElementCapabilitiesInput.link.url = 'https://<YOUR_DOMAIN>.salesforce.com/' + f.parentId; feedElementCapabilitiesInput.link.urlName = 'メッセージリンク'; feedItemInput.capabilities = feedElementCapabilitiesInput; // Mention a group. mentionSegmentInput.id = 'TARGET_USER_ID'; messageBodyInput.messageSegments.add(mentionSegmentInput); // Chatter Post ConnectApi.FeedElement feedElement = ConnectApi.ChatterFeeds.postFeedElement(Network.getNetworkId(), feedItemInput); } } }
顧客がコミュニティから投稿すると・・・
Apexトリガの処理が実行され、所有者ユーザのプロファイルにメンション付きで通知投稿が行われます。それにより次のようなメール通知が届きます。
Salesforceにログインしてメール内のリンクをクリックすると対象の投稿ページに移動できます。
これで顧客の投稿時に通知メールを送信できるのではと考えました。
FeedItemオブジェクトはChatterの投稿用オブジェクトなのでコメント投稿時には実行されません。コメント投稿時には標準の通知機能が働くので大きな問題ではないですが、正しくやるにはコメントオブジェクトにもトリガを用意した方が安全かもしれません。
コミュニティ内で社内ユーザにメンション付きで投稿しても社内ユーザのプロファイルページには表示されませんでした。ここも大きな問題にはならないと思いますが地味に落とし穴です。
例えばコミュニティユーザの連絡通知投稿をひとつにまとめるためにChatterグループを用意しても、コミュニティ側ではアクセスできません。コミュニティ側でChatterグループを作成すればアクセスは可能ですが、コミュニティに移動しないと見れませんし本来の用途としてはあまり意味のないものになってしまいました。
そもそもライセンス的に実装可能なのか不安だったのですが、これは問題ありませんでした。APIの利用を許可の設定はプロファイルで指定できます。Community Login Userライセンスが問題なければ他のライセンスでもほぼ問題ないはずです。ただしConnect APIには利用時の制約があるので注意して下さい。
最終的に通知メールを送信するためにApexトリガを使うのは向いていないと思います。投稿時にトリガで通知用の別投稿を行うということがそもそも効率的ではないと思います。投稿機能自体を自作してしまい、投稿時にかならずメンションを付ける処理にした方が、投稿/コメント関係なく通知メールが届きますし、通知メールから直接返信も可能になります。
このトリガをつかった方法で一番の障壁は顧客のプロフィールページにApexトリガから投稿した内容が表示されてしまうことです。
これも致命的な問題では無いと思うのですがあまり綺麗ではないと思います。
こんな感じでいろいろ試行錯誤してみたのですが、ApexトリガでConnectAPIをつかって通知するのはイマイチな方法だと感じました。投稿機能が自作する方が綺麗なシステムになると思います。
少し前のバージョン用ですがまだ利用できると思います。
作成済みのレポートを抽出するレポートを作成。...できないと思っていましたができました。標準のレポートタイプでも作成できますが、カスタムレポートタイプをつくるとより多くの項目を利用することができます。
フォルダやレポートタイプの他にカスタムオブジェクトも表示できるみたいです。
カスタムオブジェクトを削除するときに削除対象オブジェクト用のレポートを一覧表示して確認するといったことができるかもしれません。
Chatterをつかって社内にレポートリンクを共有する方法についてです。Chatterでは特定の内容毎にグループを作成して情報共有や議論を行うことができます。そういったときにレポートを共有してどのような状況かを報告したりできると便利です。
レポートページのURLをコピーしてChatterに投稿するのもいいですがより簡単に投稿する仕組みが用意されています。フィード追跡を有効化する方法です。設定から有効化できますがレポートオブジェクトに対しても有効化できるようになっています。
レポートのフィード追跡を有効化するとレポートページにコラボレーションボタンが表示されます。これをクリックするとChatterの投稿フォームが表示されます。
あとは通常通り共有したい人またはグループにメンションをつけて投稿するだけです。
こんな感じにレポートのChatterフィードでやりとりができます。
他のユーザはメンション時に指定したChatterグループのページで投稿を確認できます。投稿の一番上にレポート名のリンクが表示されるのでこれをクリックするだけでレポートページに移動できます。
最近追加された新機能というわけではないのでSalesforce Classicでも利用利用可能な機能です。
定期的に利用するレポートなどはレポートフィードで情報交換すると過去に行われたやりとりが記録として残り一元管理されるので便利だと思います。
File Connectの機能を利用すればChatterファイルとGoogleドライブの連携ができるようになります。
最近設定しようとしたところ、Googleドライブの設定画面が新しくなっていたりしたので2017年版ということで確認してみました。
まずは、設定のFiles Connectで有効化を行います。
続いて権限セットを作成します。これで個別に権限を付与できるようになります。
システム権限にFile Connectが用意されています。
権限セット作成後は対象ユーザに割り当てます。
次はGoogle側の設定です。下記URLのページに移動します。
https://console.developers.google.com/project
プロジェクト作成ボタンを押すとプロジェクト名入力画面が表示されます。画面に従いプロジェクトを作成するとAPIを選択できるページに移動できますので、Google Driveと検索します。Google Drive APIというのがあると思いますので、それを選択します。
選択後、画面上側に有効にするボタンがあるのでクリックしてください。
画面の右上に認証設定ボタンが用意されています。
入力はこんな感じでいいと思います。
認証設定でURLを聞かれますがこれは後で設定します。ひとまずは下記を入力すればいいみたいです。
画面に従い操作を続けるとクライアントIDが発行されます。
クライアントIDが発行されたらSalesforce側に戻り認証プロバイダの設定を行います。
ここの入力内容は下記ヘルプに詳しく記載があります。
設定が終わるとコールバック URLが生成されるのでGoogle API設定のページに戻って差し替えます。
Salesofrceの外部データソースの設定にアクセスします。
つぎのように入力します。
設定を進めるとGoogleの認証ページが表示されたりします。外部データソースの作成が終わったら検証して同期をクリックします。
チェックをつけて同期ボタンをクリックすると外部オブジェクトが作成されます。
こんな感じです。
続いて各ユーザが認証作業を行います。私の設定の外部システムの認証設定から行います。→これは管理者ではなく各ユーザが自分で行います。
ここまでできたら設定中に作成した外部オブジェクト用のカスタムタグをつくってビューなどからデータを参照してみてください。アクセス権がないと表示されると思います。
プロファイルから外部データソースの利用権限を付与できます。
※追記:プロファイルよりも権限セットで付与した方が管理が楽になりました。
外部オブジェクトは開発中になっていないか確認し、なっている場合はリリース済みに変更してください。
これで設定完了です。Chatterタブに移動してファイルページを開いて下さい。Googleドライブのファイルにアクセスできるようになっています。
最後に設定中にホームタブが非表示になってしまった場合は、下記リンク先の手順で修正できると思います。
Files Connectの機能を使えばChatterファイルからGoogleドライブのファイルにアクセスできるようになります。
Salesforce ClassicではChatterタブから見れるのですがLightning Exprienceでは表示されませんでした。
ファイル関連リストに移動してもダメそうです。
試しにファイルタブの方を確認してみました。表示していない場合はアプリケーションランチャーからアクセスできます。
試してみたところファイルタブの方で無事表示されていました。
Files Connect利用時には次のようにアプリケーションにファイルタブを出しておくと良さそうです。
Classic版でもファイルタブがあったほうが便利になると思います。
Apexテストクラスで標準価格表IDをSOQLをつかって取得するとき、システム項目ではないので@isTest(SeeAllData=true)を宣言しないと取得することができません。そのため次のようにメソッドレベルで宣言して取得したりします。
SOQLクエリはこんな感じです。
ですがこんなことしなくてももっとキレイに実装する方法がありました。
Test.getStandardPricebookId()を使う方法です。
次のように宣言すると標準価格表のIDを取得できます。
Id pricebook2Id = Test.getStandardPricebookId();
これをつかって直したのがこちら。
変更後にテストクラスを実行するとエラーなくテストできました。
このメソッドはSummer'14の頃に追加されていました。不要なSeeAllDate=trueの宣言もなくなりキレイに実装できて便利です。
http://successjp.salesforce.com/features/pdf/Summer14_ReleaseNotes.pdf
Test.getStandardPricebookId()を使う方法はQiitaで知りました。
プロセスビルダーをつかえばワークフロールールと同じようにレコードの作成と更新時に処理を行うことができます。さらにワークフロールールではサポートしていなかったChatter投稿も行うことが可能です。Chatter投稿では特定のユーザにメンションを付けることも可能となっています。
ですが実際にメンションを行う場合、動的に切り替えたいというケースが多々あると思います。そんなときは次のような書き方がサポートされています。
@[{![Contact].OwnerId}]
こんな感じです。
Name項目ではなくユーザIDを指定することでメンションとして認識される仕組みとなっています。数式のID文字列が認識されるかはちょっと確認してみませんが、おそらくサポートされるのやユーザの参照項目ぐらいだと思います。
所有者などユーザ項目の値にはコミュニティユーザを指定するケースもあると思います。
これで社内組織からレコード更新時に特定のコミュニティユーザにメンション通知できそうですが、実際に投稿された内容を見るとアクセス権限が付与されていないことがわかります。
Chatter投稿先をプロセスビルダーで指定していないためです。
もしかするとどこかで指定できるかもしれませんが、おそらくサポートされていないと思います。
社内ユーザがApexバッチなどで一括処理を行いその結果をコミュニティユーザにChatter経由で通知したい。と思ってもおそらくこの方法では対応できないと思います。(検証はしていませんが社内ユーザがコミュニティ組織に移動して処理を行えばもしかするとうまくいくかもしれません。)
またDEV環境で再現できなかったのですが、ユーザの参照項目をつかって動的にメンション指定する際にそのユーザがレコードのアクセス権限自体をもっていない場合、プロセスビルダーで認識されないと思われます。その結果、メンション指定されているのにユーザIDが存在しないことでシステムエラーが発生します。(再現しなかったのでもしかすると設定中にうっかりミスがあっただけかもしれませんが...) プロセスビルダーのシステムエラーメッセージは原因を確認しずらいので注意が必要です。
Files ConnectをつかえばChatterファイルからGoogle Drive APIをつかってファイルを参照できるようになります。
この機能を利用するときに注意するべき点があります。OAuth同意画面のユーザーに表示するサービス名を設定する部分です。
ここに入力した値がSalesforceからGoogleドライブに接続する際の認証画面にタイトルとして表示されます。この値ですが何を入力しても問題ないわけではありません。Googleドライブにアクセスするので「Google Drive」にしようと設定したことがあります。
その結果、Googleから利用規約に違反しているので3日以内に修正対応してください。改善されない場合は対象プロジェクトを停止します。と通知メールを受け取ることになりました。
Googleの製品と誤認させる名称は許可されないようにチェックする仕組みがあるみたいです。(改めて考えてみれば当然の仕組みですが...)
こうした状況になってしまった場合ですが、「異議を申し立て」的なボタンからサポートに連絡することができます。(この辺りの手順と詳細については通知メールに記載があります。)
ボタンの名称が少し怖い感じがしますが利用してもぜんぜん怖いことにはなりませんでした。Google API Developer Consoleのページから利用できるのですが、ページは日本語で記載されているので内容をよく見て判断することができます。
基本的にはどのように修正したかをサポートの方に報告するための機能となっていましたが、修正方法がわからない場合も質問することができるようです。困ったときは放置せずにきちんと問い合わせを行うと丁寧に対応してもらえると思います。
今回は通知メールに記載されたとおり、同意画面の表示内容を修正して「異議を申し立て」ボタン経由でサポートに連絡したところすぐに解決しました。異議という単語でなんとなく悪いことをしている気分になりますがそんなことはないのできちんと対応した方が良さそうです。
利用規約違反の通知を見て慌てて設定を削除して対応しようとすると逆にサポートへの連絡ができなくなってしまうと思います。そうすると利用規約違反の記録が残り続けることになる可能性も考えられます。(確認はしたことありませんが) 設定削除による対応は何も解決しないのでやらない方がいいと思います。
今回はGoogleでしたが他のサービスでも同じようなチェックがあると思いますので、製品名を認証タイトルに指定するのは避けたほうが良さそうです。Files Connectの認証情報設定を行うときはこうしたことにも注意が必要となります。
Chatterにあるトピックはハッシュタグの延長線的な感じで利用することができます。社内でどの話題が多いのかを管理するための機能になります。
そしてCommunity Cloudにもトピックという機能があります。こちらはすごくてトピックの情報をつかって新しいページを自動生成したりといった使い方ができるみたいです。
設定画面はこちら。
ここで気になる点があります。Community CloudのトピックとChatterのトピックは同じものなのかという点です。Community Cloudのトピックの利用用途を見るととても同じに見えなかったのですが確認してみました。
新規ボタンから次のように作成します。
作成後Chatterのトピックを確認してみました。同じものの場合は作成したトピックがChatter側にも表示されると思います。
その結果・・・表示されました。
Community CloudのトピックとChatterのトピックは基本的には同じものでした。ですがCommunity Cloud側の場合主要トピックやサブトピックなど便利な仕組みが用意されています。
最後にコミュニティ向け組織と社内向け組織ではトピックの管理は別物として管理されます。社内でトピックを沢山登録してもコミュニティ側では再度登録を行う必要がありました。
Salesforce Success CommunityはSalesforce1モバイルアプリからの利用がサポートされていません。そのため基本的にはPCからの利用になると思います。
モバイルブラウザから利用できなくはないのですが、文字が小さくなりますし使いづらいと思います。
ですがこの問題を解決する方法があったみたいです。「/one/one.app」を使うやり方です。Salesforce1モードに切り替えてくれるURLですがSuccess Communityでも利用できます。
下記URLでアクセスできました。
https://success.salesforce.com/one/one.app
モバイル端末からアクセスすると次のようになります。
モバイル端末のSafariなどで先程のURLをブックマークしておけば快適に利用できると思います。操作性はSalesforce1モバイルアプリには負けますが通知機能やグループ移動など必要な操作はモバイル端末からでも問題なく利用できました。
最後にブックマークの他にホームに追加の機能も試してみました。
これでホームにショートカットアイコンを表示できます。
Safariのヘッダーとフッダー部分が消えスッキリました。
・・・ですが自分のやった感じではアプリ利用後すぐにログアウト状態になってしまうので毎回ログインする必要ありそうでした。Safariのブックマークとして利用する方がログイン状態が暫くの間保持されるので便利そうでした。
Salesforceのオブジェクトにはコンパクトレイアウトという設定が用意されています。Salesorce1モバイルアプリで一部項目を見やすい位置に表示するための設定です。
あまり使いみちの無い設定だと思っていましたが、Lightning Exceperienceの登場で用途が広がっていました。詳細ページの下記赤枠の部分にコンパクトレイアウトで設定した内容が表示されます。
ルックアップ項目でもコンパクトレイアウトの設定が適用されます。(上限は4件と思われます。)
コンパクトレイアウトですが標準オブジェクトはデフォルトである程度設定されています。
電話項目は1つにグルーピングされる仕組みです。
※カスタムオブジェクトの場合はName項目だけデフォルト表示されるようになっています。
コンパクトレイアウトはカスタマイズで任意の項目を表示するように設定できます。
表示される項目数に上限はありますが比較的柔軟にカスタマイズできると思います。細かい部分ですがきちんと設定しておくとLightning Experienceが使いやすくなりそうです。