批量修改是我们在系统操作中，常见的效率操作，对我们工作效率提升有很大帮助。
比较常见的是对同一类数据的字段全部修改。
B端产品的字段就更多了，经常一个页面，涉及到多处的字段修改，常见的解决方案是，把所有的字段都放在一个页面上，用户想改哪个就改哪个，然后统一提交。
这样做的优点，是聚合了所有要修改的字段，统一入口，用户查找方便，可批量修改的字段一目了然。
但在b端产品中，我们会面临多场景，用户选择难，关联逻辑多的问题，经常有修改有大量前置条件，如果全部在一个页面展示，扩展性差，冲突多。
每个字段，每个场景的批量修改旅程和体验是不一样的。针对以上问题，我们可以按以下步骤解决批量修改的问题
第一步，对批量修改的字段进行分类
我们可以按场景，类型，角色，权限进行过滤，然后在看字段是否可直接修改。
1.无关联字段，可直接修改的字段，例如：备注
2.有关联字段，调整一个字段，需要对其他字段进行关联调整，例如：调整地址，联系人，电话就可能需要同时调整
第二步，整理每个修改的旅程地图
针对每个批量修改，在B端产品中，可能都是个针对不同场景需求的小功能，所以对个别修改，我们同样要梳理旅程地图和流程图。
第三步，字段的分类归类设计
无逻辑关联字段，可按场景，使用频率，进行分类
无逻辑字段，如是同一类型，可以归类在一个修改页面，减少用户的选择成本
例如备注
第四步，对每个场景，有逻辑的字段，进行页面聚合设计，关联设计。
保证修改字段时，所需的条件都在一个页面上。
有关联逻辑的字段批量修改，修改页面可能有多个关联的字段需要修改，对关联的触发，我们要落在主要修改对象上。
例如：规则是，地址如修改为外地，必须更新联系人和电话。本地则不强制更新联系人和电话。
我们的交互触发点就要落在地址上，对输入地址进行判断，按规则，启用对应的字段修改。
第五步，所有批量修改页面，聚合在一个批量修改的入口内
采用hover的交互方式，保证用户快速选择要批量修改的字段。
至此，一个针对B端产品的多字段的批量修改，我们就完成了。
用户可根据自己的角色和场景，快速选择要操作的修改
下拉显示修改内容更直观，更易选择
批量修改扩展性更好，有更多修改字段也不怕
提交时只需提交当前任务的结果，不再同时提交多个校验，减少报错
这样做批量修改，是不是更好呢
