# CRS：Oracle Petroleum 客户入职平台的现代化实践，从 Jotform 到结构化审批工作流

> CRS是一个面向Oracle Petroleum Toll Blend部门的内部客户入职平台，采用Next.js 16、TypeScript和Drizzle ORM构建，通过角色驱动的审批链替代了原有的手动Jotform流程，实现了从客户填表到ERP编码的全流程数字化管理。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-16T03:45:48.000Z
- 最近活动: 2026-05-16T03:48:49.482Z
- 热度: 152.9
- 关键词: 客户入职, 工作流, 审批系统, Next.js, TypeScript, Drizzle ORM, PostgreSQL, 企业应用, 角色权限
- 页面链接: https://www.zingnex.cn/forum/thread/crs-oracle-petroleum-jotform
- Canonical: https://www.zingnex.cn/forum/thread/crs-oracle-petroleum-jotform
- Markdown 来源: ingested_event

---

## 背景：传统客户入职流程的痛点

在企业级客户管理中，传统的入职流程往往依赖分散的工具和手动操作。Oracle Petroleum Toll Blend部门此前使用Jotform收集客户信息，但这种方式存在明显的局限性：数据分散在不同表单中，缺乏统一的审批追踪机制，销售代理与内部审核人员之间的协作效率低下。更重要的是，随着业务规模扩大，手动处理大量客户注册表单不仅耗时耗力，还容易出错，难以满足合规审计的要求。企业迫切需要一套结构化的、可追溯的数字化解决方案。

## CRS的定位与核心目标

CRS(Customer Registration System)应运而生，作为Oracle Petroleum Toll Blend部门的内部客户入职平台，其核心目标是取代手动Jotform工作流，构建一个基于角色的结构化Web系统。在这个系统中，销售代理代表潜在客户提交客户注册表单(CIS)，内部利益相关方通过可追溯的审批链进行审核、背书，最终批准或拒绝申请。这种设计不仅提升了流程透明度，还为每个环节建立了明确的责任边界。

## 技术架构：现代全栈选型

CRS采用了当前主流的现代Web技术栈。框架层面选用Next.js 16.2.1配合App Router，充分利用服务端组件带来的性能优势。开发语言使用TypeScript，在大型团队协作中提供了更强的类型安全保障。样式方案采用Tailwind CSS v4结合shadcn/ui组件库，既保证了视觉一致性又提升了开发效率。认证层使用NextAuth v5实现JWT会话管理，数据库访问通过Drizzle ORM操作PostgreSQL(Neon托管)，文件存储则依托Vercel Blob服务。这套技术选型兼顾了开发效率、运行时性能和运维便利性。

## 角色体系与权限设计

CRS的核心创新之一是其精细化的角色权限体系。系统定义了八种角色，每种角色对应特定的业务职能和系统权限：销售代理(sales_agent)负责提交CIS表单并在客户完成后填写代理部分；销售经理(sales_manager)拥有团队提交的只读视图；财务审核员(finance_reviewer)负责审查文档和信用评估，可转发给高级审批人或退回给代理；法务审批员(legal_approver)专责经销商类型客户的审核；高级审批员(senior_approver)拥有最终批准或拒绝的决策权；销售支持(sales_support)在批准后填写账户类型、价格表和增值税信息；项目开发专员(project_development_specialist)负责将客户标记为已录入ERP；管理员(admin)则拥有全量可见性和用户管理能力。

## 工作流引擎：状态机驱动的审批链

CRS的工作流引擎是整个系统的核心。客户填写表单后，由代理补充代理部分信息，随后根据客户类型分流：经销商类型进入法务审核，其他类型直接进入财务审核。审核员可选择转发至高级审批人或退回给代理。退回的表单允许代理重新上传替换文档后再次提交，系统会将表单路由回同一审核员。只有高级审批员拥有拒绝权限，且拒绝是终态，不允许重新提交。审批通过后，销售支持填写账户详情，最后由专员完成ERP编码。整个流程涉及七种状态转换，每种转换都触发相应的通知和审计日志记录。

## 关键业务规则与边界情况

CRS设计了一系列关键业务规则来确保流程的严谨性。客户类型决定路由路径——经销商必须经过法务审核，其他类型直接进入财务审核。经理角色严格只读，只能查看团队提交但不能执行任何工作流操作。代理代码自动盖章机制确保每个CIS记录在创建时就永久关联代理身份。财务审核要求必须上传CFO签署文档(docSirRestySigned)后才能转发给高级审批人。审计追踪覆盖每个动作，所有状态转换都记录在workflowEvents表中，包含执行者、动作、备注和时间戳。通知系统同时支持邮件(Gmail+Nodemailer)和应用内通知两种渠道。

## 数据模型与存储设计

CRS的数据库设计围绕四个核心表展开。users表存储所有平台用户信息，包括角色、代理代码、经理分配和激活状态。cisSubmissions表承载CIS表单数据、状态、所有文档URL(JSONB格式存储)、财务评估结果和销售支持字段。workflowEvents表作为完整的审计日志，记录每个表单的每次操作历史。notifications表管理应用内和邮件通知记录，按接收人维度组织。文档存储采用Vercel Blob服务，数据库中仅保存完整的Blob URL数组。这种设计既保证了文件访问的可靠性，又避免了数据库膨胀。

## 前端组件架构与用户体验

CRS的前端组件架构体现了模块化和职责分离的设计思想。actions目录下按角色组织操作表单组件，涵盖填写、转发、退回、批准、拒绝、编码等操作。ui目录包含shadcn/base-ui基础组件，cis-card和cis-info-card分别处理提交列表和详情展示。audit-timeline组件以时间线形式展示工作流事件历史，workflow-stepper可视化审批链进度，workflow-handoff显示当前处理人和下一环节。文档上传采用doc-upload-slot和agent-doc-section组件，支持逐文档审核和驳回。整体界面通过Framer Motion添加适度动画，提升交互体验。

## 部署与运维实践

CRS设计为部署在Vercel平台，充分利用其无服务器架构和全球CDN。环境变量配置涵盖数据库连接、认证密钥、签名验证密钥、Blob存储令牌和邮件服务凭证。本地开发支持通过.env.local文件管理配置，提供完整的种子数据脚本用于演示环境初始化。数据库迁移使用Drizzle Kit管理，确保 schema 变更的可追溯性。生产部署时需注意AUTH_URL需设置为实际生产域名，AUTH_TRUST_HOST设为true以支持Vercel的代理架构。这种部署模式实现了从开发到生产的平滑过渡。

## 总结：企业工作流数字化的参考范式

CRS项目展示了如何将传统的手动业务流程转化为结构化的数字工作流。通过精细的角色权限设计、清晰的状态机驱动工作流、完整的审计追踪机制，CRS不仅解决了Oracle Petroleum Toll Blend部门的实际业务痛点，也为类似的企业内部系统建设提供了可借鉴的架构范式。其技术选型紧跟现代Web开发趋势，代码组织清晰，文档完善，是一个值得研究的企业级应用实践案例。