工作流引擎或工作流系统，应该致力于工作流引擎模型的设计，业务流程的抽象，以及业务流程的流转，这些是工作流系统的重要部分，把这些设计好了，一套工作流系统也就具备雏形了。
但是业务流程的流转往往是需要有特定的人，特定的角色等的参与的。在业务流程建模，流程实例的流转，都是离不开应用系统中的用户系统。可以说用户系统是工作流系统的不可缺少的部分，因此工作流系统也必需要涉及到用户系统的设计与实现。
工作流系统作为开发部件，集成到用户的应用系统中。有些模块可以直接被应用系统调用，同时流程引擎又封装了很多api函数，开发人员也可以通过类库，api函数等的来集成流程引擎的功能。
一般来说，应用系统均会包含有用户系统，组织机构等的维护模块，有独立的设计和实现。
工作流系统和应用系统的集成，首先就要面临用户系统的集成：
工作流系统本身也需要包含用户系统的设计与实现。集成应用系统后，应用系统也有自己的用户系统。需要将这两套用户系统合二为一，因此在eworkflow流程引擎中，设计了一个映射表，作为中间层。来实现将应用系统的用户系统映射到流程系统中，使得流程系统中业务流程建模，定义，流转中使用的用户角色等都关联到应用系统。
一个fcuser.xml映射表的内容如下：
根据关键字，来填写相应的表名，在流程引擎中，根据这些关键字来读取相应的value值，作为表名。
工作流系统中，所有关于用户系统的数据来源（包括前台后台的界面显示的）均来自这个映射表。
因为工作流系统中，只涉及到使用用户系统，例如查找，显示列表等。不涉及到用户系统的维护（用户系统的维护，在应用系统中有独立的完成），因此，映射表中，只需要关联几个常用的字段，例如 用户编号，用户id,用户名称；角色id,角色名称。同时还有一个工作组的概念（或者临时的工作组），如果应用系统中没有工作组，就可以不设置关联，eworkflow自动取eworkflow中的工作组表。
映射表中所有字段，均按照字符型的来关联，如果和应用系统的字段类型不匹配，则需要修改流程引擎user包中的用户对象类了，就是表的实体类。使得字段类型保持一致。
因为流程引擎中用到用户系统字段都相对少，所有在业务流程建模等显示的列表字段都相对简单，如果需要增加多一些的信息，在需要扩展这些列表的功能。在工作流系统中，所有列表显示等的页面，均是用eform自定义表单来实现的，通过表单设计器，可以快速的修改这些页面的显示。
工作流系统中的用户系统，也有一个设计和使用的过程，当设计和应用系统的用户系统的设计相差太大，也可以通过简化＋扩展业务类的方式来实现，因为工作流系统中涉及到用户系统的部分，就是在业务流程流转中的权限会涉及到，每个节点的使用权限。可以通过扩展条件类，前置后置函数等来达到。
c#条件类的接口
public interface Condition
{
bool passesCondition(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps);
}
c#函数类的接口
public interface FunctionProvider
{
void execute(System.Collections.IDictionary transientVars, System.Collections.IDictionary args, PropertySet ps);
}
java条件类的接口
public interface Condition {
public boolean passesCondition(Map transientVars, Map args, PropertySet ps) throws WorkflowException;
}
java函数类的接口
public interface FunctionProvider {
public void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException;
}
当工作流系统未集成到应用系统时，也可以通过修改这张映射表，读到用户系统表，就可以使eworkflow工作流单独能运行。
