Slack MVP Spec
Introduction
Top Ranked Integrations
See Drupal
See Zapier
Marketing Value
Slack is growing at a crazy pace. It is probably the fastest growing business software company in the world today. Slack is adding about 10,000 users every week, and Annual Recurring Revenue of $1,000,000 every 11 days.
We could be the first workflow tool to have a tight integration with Slack. Slackflow - Brian coined that, if only we could trademark that! :-)
See how other companies integrate their software with slack and why - http://venturebeat.com/2015/05/15/think-slack-is-just-a-billion-dollar-chat-app-you-havent-seen-how-this-company-is-using-it/
We could essentially ride their wave of growth, potentially.
High Level Description
How It Would Work
We would create almost an identical entity to Groups, and it would be called Channels. The Channel could be of type public or private. The assignment of tasks in ProcessMaker would be either through a Channel or individual user.
Potentially, the user could select which Channel or user the workflow would be routed to by simply invoking the username with @ in front of it, in typical Slack style.
A Slack user could, from any chat/channel/group type /pm-time-off /pm-purchase and pass params with it, just like a shell script so to speak.
That would trigger a ProcessMaker custom REST API endpoint. The endpoint would kick off a workflow and then the case would be routed to the correct Channel or user.
If the case were routed to a Channel, anyone in that Channel could approve the request, just like the unassigned functionality. In fact, we would use the self service functionality in ProcessMaker for this.
We can embed links into the text, so we could do something similar to the Actions By Email where a user can click on the approve or reject links.
The user could also simply type /pm-route <case_number> approve or /pm-route <case_number> reject from anywhere to approve or reject the case.
The Ideal Workflows
These workflows would be standard and only allow minimal configuration - targeting companies of 40 employees and up, i.e. smaller companies and organizations than those that usually use ProcessMaker.
Based on the idea outlined above, the workflows would work in such a manner:
Time Off Request
A user would type “/pm-time-off from next thursday until the 28th because we found great rates on groupon” or “/pm-time-off for 2 weeks starting the 17th of July because I am going on my honeymoon”. This would hit the REST API endpoint that would trigger the workflow to begin and would then be routed to either a direct supervisor or Channel. The exact Channel/user could be configured through the setup process described below.
Then, the user in a Channel or private message could approve the request in an Actions by Email style or by simply typing “/pm-route 590 approve”.
If there were a multi step approval, the workflow would just continue in this way.
Through ProcessMaker triggers, just as always, we could interface with an HR system to automatically deduct the days of leave.
If a user wished to see their inbox, they could type “/pm-inbox” and they would see all the cases that they have access to participate in.
If a user wished to add a case note to a case, they could type “/pm-case-notes do you remember what happened last time you went away on vacation? Make sure it doesn’t happen again! :-)”.
If a user wished to check on a status of a particular case, they could simply type “/pm-status 256” and they would get a message back telling them the status for case number 256. For example, it could be Pending Approval. The status would be particular to the context of the workflow and not the ProcessMaker statuses of DRAFT,TODO,CANCELLED,COMPLETED etc.
We would also have a concept of publish/subscribe to a case. With this concept, a user would automatically be subscribed all activity of a case. If the case was routed, if a case note was added or anything else happened to it, all participated users would received notifications as a Private Message.
Purchase Request
The user would type “/pm-purchase a new computer for $1000 from amazon because I spilled coke on my old one”.
The workflow would operate in a similar fashion to the Time Off Request.
The Project
Setup
The setup will be performed in Slack. The idea is to not require the user to log into ProcessMaker at all.
We will give the users the ability to use human speech. “Everyone”, “all” and others.
The user will not need to specify the hashtag for channels but should be able to if they want to, we will handle all that in the code.
In terms of setting up the Processmaker instance, this will not be necessary as the project will be cloud based and the idea is for the users to not have to log into ProcessMaker at all.
ProcessMaker will have already been set up for them and all that they will need to do is simply connect to it.
General Setup
Item | Description |
---|---|
Channel creation in ProcessMaker | Groups will act as channels because the concept is the same. So, for each channel that exists in Slack, a group will be created in ProcessMaker automatically. |
Channel assignment to tasks | A bot will ask for the name of each of the channels that will be assigned to each task in each workflow. For more details, see below. |
User and channel import | When ProcessMaker and Slack are connected, ProcessMaker will suck in all the users and channels that are in the team. A nightly sync will also be performed via cron to ensure that the information is kept up to date. Because we don’t have access to the users passwords, for the login credentials that we will create in ProcessMaker, we will use: Username: user_name in Slack e.g. ethnp Password: user_id in Slack e.g. U02FG73JP We will create the authentication module as a separate module so that we can easily extend/modify the authentication piece later down the road. Thinking further in the future, ldap integration with Slack, Google SSO integration etc. We would need to somehow tie it to the user in Slack. We would need to investigate this further, but in the meantime, by writing the authentication piece as a separate module, this will give us the flexibility to do this later down the road. |
Installation script | We will have an install script when ProcessMaker is first run. This will be performed in Slack as “/pm install”. It will basically store the token received from Slack, so that we know that all future requests must be authenticated with that specific token. In this manner, by using this extra authentication token, we are essentially having 3 keys for logging in:
If someone tries to access the ProcessMaker workspace without all 3 of those keys, they will not be able to log in. Additionally, we will create a table to store the key, so that we can have potentially multiple keys stored in the table so that a company can have multiple teams, so therefore different slack ids, but still share the same ProcessMaker instance. So, we can have a workflow start in one team, say development, and go to hr. They would be completely separate teams, but still utilizing one workflow engine. |
REST API authentication | Because we use OAuth 2.0, we cannot authenticate with Slack directly.
Here is an example of the payload: Array ( [token] => oddn3CBQPyMq8GRhWDuyKneT [team_id] => T02FG73JM [team_domain] => processmaker [channel_id] => G02FH9UBS [channel_name] => privategroup [user_id] => U02FG73JP [user_name] => ethnp [command] => /pm [text] => ) Because of this limitation, we will create a file in the services folder of our plugin that will be accessible without the need to be logged in. In this file we will check for the token that is passed from Slack and use the user_name and user_id, as the username and password to then login to the ProcessMaker REST API, as discussed in the point above. |
Time Off Request Setup
Bot (Prompt) | User (Response) |
---|---|
Which channels should have access to start the Time Off Request? | “Everyone” or “all” or “#marketing”. |
Which channels should be able to approve the request? | “#supervisors” or “#managers and supervisors and #executive-management”. |
Purchase Request Setup
Bot (Prompt) | User (Response) |
---|---|
Which channels should have access to start the Purchase Request? | “Everyone” or “all” or “#sales”. |
Which channels should be able to approve the request? | “#supervisors” or “#managers and supervisors and #executive-management”. |
Which channel is in charge of making the actual purchase? | “#purchasing” or “#managers” or “same as requestor” |
The Processes
Time Off Request
Process Flow
Tasks
The tasks that will be in the process.
Task | Type | Description |
---|---|---|
Request Time Off | Starting Task | This is where the user requests the time off. |
Approve Time Off | Task | This is where the user gets approved to take time off |
Slack Message | Trigger | This will send a notification to the user who initiated the request with the approvers decision. |
Fields
Since there will be no forms, since everything is accessed through Slack, we only need to define the fields that will house the data for each case.
Field ID | Field Label | User Filled | Field Type | Field Description |
---|---|---|---|---|
RequesterUsername | Requestor Username | N | String | Time off requestors username |
RequestorFullname | Requestor Fullname | N | String | The full name of the requestor |
RequestDate | Request Date | N | Datetime | Date of the request |
TimeOffDateStart | Time Off Start | Y | Datetime | Date the time off will start |
TimeOffDateEnd | Time Off End | Y | Datetime | Date the time off will end |
TotalTimeOff | Time Off Total | N | Integer | Total amount of leave being requested |
ReasonForTimeOff | Reason For Taking Time Off | Y | String | The reason that the requestor is requesting for taking time off |
Status | Status | N | String | The current status of the request. Options are: { Pending Approval Approved Rejected } |
Messages
All messages will take place in Slack. There will be NO email messages, as that kind of defeats the purpose of Slack. Therefore, all messages will be in the form of formatted webhook messages in either a channel or a private message between the ProcessMaker Bot and the user.
Message Title | Task | Location | Content |
---|---|---|---|
Notification to approver | Approve Time Off | Channel | Hello {{UserFullname}}, A new request for Time Off has been initiated by {{RequestorFullname}}. {RequestorFullname} has requested to take time off from {{TimeOffDateStart}) until {{TimeOffDateEnd}}. That would mean a total of {{TotalTimeOff}} days off. Would you like to Approve or Reject this request? Note: To approve or reject the request, please click on the appropriate text above, or you may type either “/pm-route 253 approve” to approve the request, or “/pm-route 253 reject” to reject the request. |
Approval notification to requestor | Approve Time Off | Private Message | Hello {{RequestorFullname}}, We just wanted to let you know, you have the best boss in the world! Your request for time off, from {{TimeOffDateStart}} until {{TimeOffDateEnd}} has been approved! For your records, the case number is {{AppNumber}}. Enjoy your time off! |
Rejection notification to requestor | Approve Time Off | Private Message | Hello {{RequestorFullname}}, We regret to inform you that your boss sucks! Your request for time off has been rejected. For your records, the case number is {{AppNumber}}. Better luck next time! |
New case note | All | Private Message | Hello {{UserFullname}}, We just wanted to let you know that there has been a new case note added to case number {{AppNumber}}. See below for the full note. “{{CaseNote_Content}}” |
Purchase Request
Process Flow
Tasks
The tasks that will be in the process.
Task | Type | Description |
---|---|---|
Purchase Request | Starting Task | This is where the user requests the purchase. |
Approve Request | Task | This is where the purchase gets approved. |
Make Purchase | Task | This is where the purchased gets made. |
Slack Message | Trigger | This will send a notification to the user who initiated the request with the approvers decision. |
Fields
Since there will be no forms, since everything is accessed through Slack, we only need to define the fields that will house the data for each case.
Field ID | Field Label | User Filled | Field Type | Field Description |
---|---|---|---|---|
RequesterUsername | Requestor Username | N | String | Time off requestors username |
RequestorFullname | Requestor Fullname | N | String | The full name of the requestor |
RequestDate | Request Date | N | Datetime | Date of the request |
RequestedItems | Requested Items | Y | Array | List of items a user wishes to purchase, including qty and price |
TotalAmount | Total Amount | N | Float | Total dollar amount of the entire purchase |
Approved | Approved? | Y | Boolean | Indicating whether or not this purchase was approved. |
DateApprovalDecision | Date of Approval Decision | N | Datetime | The date that the purchase was either approved or rejected. |
ApproverUsername | Approver Username | N | String | The name of the approver |
ApproverFullname | Approver Fullname | N | String | The full name of the approver |
Purchased | Purchase? | N | Boolean | Indicating whether or not this purchase has been purchased yet. |
DatePurchased | Date Purchased | N | Datetime | The date that the purchase happened. |
PurchaserUsername | Purchaser Username | N | String | The username of the person making the purchase |
PurchaserFullname | Purchaser Fullname | N | String | The full name of the person making the purchase |
Status | Status | N | String | The current status of the request. Options are: { Pending Approval Approved Rejected Pending Purchase Purchased } |
Messages
All messages will take place in Slack. There will be NO email messages, as that kind of defeats the purpose of Slack. Therefore, all messages will be in the form of formatted webhook messages in either a channel or a private message between the ProcessMaker Bot and the user.
Message Title | Task | Location | Content |
---|---|---|---|
Notification to requestor | Request Purchase | Private Message | Hello {{RequesterFullname}}, Your Purchase Request has been submitted. The correct person has been notified and will reach out to you with a decision shortly (hopefully)! Note: In the meantime, you can follow up with this request by simply typing into the chat “/pm-status 233” to check on the status of the request. |
Notification to approver | Approve Purchase | Channel | Hello {{UserFullname}}, A new Purchase Request has been initiated by {{RequestorFullname}}. {RequestorFullname} has requested to purchase the following items: {{RequestedItems}} Would you like to Approve or Reject this request? Note: To approve or reject the request, please click on the appropriate text above, or you may type either “/pm-route 253 approve” to approve the request, or “/pm-route 253 reject” to reject the request. |
Notification to purchaser | Make Purchase | Channel | Hello {{UserFullname}}, A new Purchase Request has been approved by {{ApproverFullname}}. The following items were requested: {{RequestedItems}} Please confirm that the items were purchased. Note: To confirm that the purchase was made, please click on the “confirm” text above, or alternatively, you may also type “/pm-route 253 confirm”. |
Notification to requester | End of Process | Private Message | Hello {{RequesterFullname}}, Guess what? Your Purchase Request was not only approved, it was also purchased. Keep a look out for the purchased items, if you haven’t received them already! |
New case note | All | Private Message | Hello {{UserFullname}}, We just wanted to let you know that there has been a new case note added to case number {{AppNumber}}. See below for the full note. “{{CaseNote_Content}}” |
Workflow Participation
All assignment rules will be self service. This will enable everything to be all related to channels, while ensuring that we can keep track of user accountability and traceability.
Once a user performs an action, we will automatically claim the case for them, perform the action they requested and then route the workflow to the next task.
In ProcessMaker terminology, subscribing to a case means: users that have participated in a case.
Slash Commands
Action | Description |
---|---|
/pm-inbox | This will return a list of cases that is in the user's unassigned view. To the user, this is their normal inbox, however, to ProcessMaker, this is unassigned/self service. This will be as a message with fancy formatting, and for each case, there will also be an approve/reject link so that a user can directly approve or reject a case from that view. |
/pm-case-note <case_number> | This will return all the case notes for a particular case number. |
/pm-case-note <case_number> <text> | This will add a note to the case notes and also broadcast to all the channels that are subscribed to this case with the note that was added. |
/pm-route <case_number> <action> | This will route a specific case number based on the action specified. For example, “/pm-route 2564 approve” will approve the case 2564. |
/pm-status | This will enable the user to check on the status of a particular request. E.g. “/pm-status 125” will return: “The status of case number 125 is: Pending Approval”. |
/pm-time-off <from_date> <to_date> <comments> | This will create a new case in the time off request process. The user will receive back a message indicating that their request has been received together with the case number for them to be able to follow up on it. For example, “/pm-time-off from today until next Friday because I need to go surfing in California”. |
/pm-purchase <items> <comments> | This will create a new case in the purchase request process. The user will receive back a message indicating that their request has been received together with the case number for them to be able to follow up on it. Maybe the case number can also act as the purchase order number. For example, “/pm-purchase 2 computers for $1000 and 3 tablets for 300 dollars for setting up the new office”. |
Webhooks
Action | Description |
---|---|
Message with approve/reject links | When a case is routed to another task, everyone in the channel will see the message that the case has been routed to a new task. In that message, there will be the information related to the case and at the bottom there will be two links, approve/reject. If a user clicks on that link, very similar to how we do the Actions By Email, the case will be routed as approved or rejected, based on which link they select. |
Notifications | Any user that is subscribed to a case will receive notifications of any and all actions taken on a particular case. This will be displayed as a webhook message. This includes whenever a case note is added, all subscribers will receive a notification with the case note Perhaps we can add the ability for users to unsubscribe from a case if they do not wish to receive constant notifications of it’s progress. This would however require further customization to perhaps maintain a database in order to maintain the pub/sub relationships and permissions, with varying levels of subscription e.g. subcribe to a case being routed but not case notes or vice-versa. |
Custom message from a ProcessMaker trigger | Custom message that can be sent via a ProcessMaker trigger to any channel, group or private message. |