Every workflow app that you can create in Celoxis has the following components:Worklfow:
A set of activities performed using the business logic on a requests. For example, Bug Tracking, Risk, etc.
State:
States: States represent "Stages" in your business processesapp. Each state is a logical check point in the process where a specific activity is expected to be performed. Every state has a Start start and end state.
For instance, in an "Order Fulfillment ProcessApp", the following states may exist: "Order Received", "Payment Authorized", "Goods Shipped", "Payment Captured", "Closed". Other states might be "Payment Not Authorized", "Order Rejected" and "Order Canceled By Customer".
Every state has a Start start and end state.
State Transitions:
Transitions are rules that define how a process transitions (moves) from one state to another. There may be many possible transitions from a state.
Workflow: These are the actions you can perform in an app. For instance, a bug in the state "Fixed" can be transitioned to "Re-open" because the bug fails a test or it may go to "Closed" because the fix worked.
Timeout Policies:
Timeout Policy determines what the process should do after a certain time has elapsed in a state. e.g. In a bug tracking system, if the bug remains in state "new" for 24 hours then it may be required to notify the manager. Similarly in a help-desk system, it may be organization policy to move requests to state "Closed" after 3 days of inactivity.
Email Triggers:
Celoxis provides a way to initiate a state transition its fixed.
Requestor: The initiator for an app. E.g. in a leave approval app, the requestor will be the person who is applying for the leave.
Triggers: Celoxis provides a way to perform actions based on email triggers from the requestor.
Requestor:
The initiator of the Workflow instance.
Initial Assignee:
The first user to whom the workflow instance is assigned as soon as it is created.
Assign To:
When performing state transitions, you must assign the workflow instance to the appropriate user for that state. When defining the State transitions, you can set the roles to whom the workflow will be assigned.
Roles
Roles are used to control security. In the "Lead Tracking" process the roles may be "Sales Manager", "Sales Co-ordinator" and so on. Roles are assigned privileges (who can do what) at the time you configure the Worklfow.
You can also define which user plays a particular role.
State Managers: State managers are users who are responsible when an app is in a particular state. They receive notifications (if enabled) for delayed items, etc.
Timeout Policies: Timeout policies help you define rules on what should happen if an app remains in a state for a given time. For example, In a bug tracking app, if the bug remains in the "Open" state for 24 hours then it may be required to notify the state manager.
Security: With each custom app, you can define roles, assign permissions and specify users who can play those roles.