月度归档： 2017 年 9 月

Salesforce的Tag（标签）-一天一个标准功能系列

这两天有小盆有提到了一个需求，
说客户一直在用MacBook，
MacOS提供了一个标签功能，客户可以将一组散落在不同位置的，不同类型的文件，打上同一个标签，
之后可以很方便的管理同一标签的文件。
所以客户也想在Salesforce里面使用这种功能。
问我怎么办才好。

我问他，“你想怎么实现呢”
“我想，首先要确认都有哪些obj需要被打标签”
“很好，然后呢”
“然后，我可以在这些obj上都加上一个自定义字段，叫Tag，然后在所有的Layout上把这个Tag字段放出来。”
“唔。。。可以实现，但是，用户怎么查看都有哪些数据被打了相同的Tag呢？而且，如果多个用户都需要打Tag，怎么保证互不干扰，并且互相保密呢？”
“啊。。。。我想想，查看的话，我可以写一个VF，通过查询把所有的表都查一遍，多个用户就麻烦了。。。我想想。。。”
（过了半个小时）
我问道，“有想法了没？”
“有了！我不加字段了，那样不科学！”
“很好，那你想怎么做呢？”
“首先，我建一张表叫Tag__c。然后关联所有需要打Tag的obj。之后Sharing Rule设置成private。查看Tag的时候，用ListView进行过滤，把所有相同Tag名字的数据都显示出来。(得意)”
“那打标签的动作怎么解决。就是打算如何在数据上点一下就加上一个标签。”
“我打算用Quick Action或者自定义Button，将它们添加到所有的Layout上，这样在Detail画面直接点一下就能打上标签了。”
“那如果有个标签我想给所有人看呢？(坏笑)”
“那样的话我得用Sharing Rule，将Share to All Flag为True的数据Share给所有人。”
“累不？”
“累。。。。”
“你听说过标准Tag功能吗？”
“我就知道！！！”

标签，无论是在现实世界还是计算机世界，都是管理资源的良好手段。
所以Salesforce也原生提供了Tag功能，我们要做的，就是将其开启就好。
官方文档，点击这里

开启之后，查看标签的效果是这样的

点击[Personal Tags]之后

开启之后，在数据的详细画面上，可以点击右上的[Edit Tag]添加标签。

不过，Tag也不是无限打的，是有个数限制的

开启的方法为，
Setup -〉Build -〉Customize -〉 Tags -〉Tag Setting
开启Personal Tag之后，可以选择是否在Report等之上使用Tag，与显示Tag功能的PageLayout。

需要留意的是，Salesforce官方文档提到了两种Tag，分别是Personal Tag和Public Tag，
但是DE只能开启一种Personal Tag。
只有真正的Production才能开启Public Tag。

有了这个功能，用户可以跨越表关联，方便的管理一组数据了。

有同学质疑我的“一天一个”，我的意思是。。。。我花了一天时间才能写一个的。。。。

关于Salesforce的组成

小时候看CCTV播放的纪录片，里面讲抗日战争日期中国空军的事情。
到现在都能很清晰的记起其中一段。
当时是采访一位老兵，说当时根本没有时间进行系统训练，
所有的飞行员都是简简单单练练起飞降落开机枪就上天作战了，
根本没机会像现代空军一样，要系统的学习机械原理，飞机构造之类的才能上天。
简单的比喻就像开车一样，能把车开走不一定需要知道车为什么能开走，引擎是什么烧的，动力是怎么传导的。

做开发也一样。
特别是Salesforce。
作为Salesforce从业者，也许精通admin，玩转401，熟练掌握501。
但不一定需要了解Salesforce平台是由什么构成的。

对于大部分从业人员来讲，了解了这些也不一定对日常工作有什么帮助。更何况还有可能占用宝贵的娱乐时间。
而且虽然作为Salesforce从业者，仍然有大量的英语困难症患者（日语也一样），更成为了止步不前的借口。

其实还是建议所有想在Salesforce平台好好做下去的从业者，认认真真的读一读官方提供的Salesforce基本原理。
毕竟想跳的更高，就要蹲的更深。

干了这些年，根据经验总结。
我把Salesforce里面所有的东西分成三类。
第一类是云计算的核心，Metadata元数据
第二类是数据
第三类是设定

Metadata是其中最好理解的，也是最难深入理解的。
有经验的人知道我们对系统做出的大部分（注意，并不是所有）改动都会在Metadata上有所体现。
我们在Deploy的时候，Deloy的具体source也是MetaData文件。
MetaData可以视为是定义了Org中的一切。
老手甚至可以通过手动编辑MetaData让系统变成自己想要的样子。

如果MetaData使用来定义这个系统是什么样子。
那么数据就是这个系统的血肉，真正让系统的存在有了意义。
做Java系统时间长了的人，总觉得系统=代码。
而Salesforce将数据的重要性提到了一个新的高度。
几乎所有的改动都在围绕着数据。
收集数据，处理数据，显示数据。
数据还要分为业务数据，功能数据，系统数据。
业务数据就是系统用户日常业务开展需要数据，客户信息啊，商品列表啊，这些也是开发人员轻易不能动的内容之一。
功能数据，就是为了实现一些功能，需要储存参数的临时表， Custom Setting，或者记录功能执行记录的数据。
这部分数据用户是看不到也不需要看到的，但是又是系统正常运转的必须部分。
最后还有大量的系统数据，这些数据默默的维持着系统的基本运转，其中有一些表甚至不对开发者开放。

在这个世界上， 事情从来不会非黑即白。如果MetaData和数据泾渭分明，世界还是很美好的。
但现实是残酷的。并不是如理想一般，这个东西不是属于MetaData，就是属于数据。
在Salesforce里面，存在这大量双轨制的东西。
比如Profile，Role，Apex，VF等等，
这些既存在于MetaData，又存在于数据中。这样就等于赋予了这些东西两种截然不同的属性。
MetaData和数据的根本区别在于什么呢？
MetaData是定义，可以通过工具部署。是骨架。
数据不需要部署，可以直接导入，直接修改。是血肉。
这些东西就如粒子一般，拥有波粒二象性。
这里跑题太严重，就不展开了。

除了MetaData和数据以外，还有一些看得见摸得着的东西，不属于任何一种。
我称呼它们为设定，它们拥有这最顽固的性质，
除了手改，无法部署，不能导入。而且存在于各个角落。
最复杂的情况比如，在Profile本身已经是双规制。
结果Session Timeout设置和Password Policies这个两个俨然应该隶属于Profile的设定，
却不存在于MetaData和数据中任何一方。
甚至Profile的Copy功能也会将这两个设定无视掉。

具体分类的名单，等整理完之后再发吧。

// Upadate1

我还是想简单了，其实Metadata和数据的界限要更模糊一点。
有些我原来以为只能通过Metadata修改的东西，最后在sfdc后台其实还是一张表。