Custom create form and workflow

[Erik Arendall]

I have a ISO process that I need to layout in Jira. I am wanting to use it for tracking R&D projects and also allow users to generate project requests. Here is a quick snapshot of the workflow i'm looking to replicate in Jira.

1. User will fill out a "Project Request Form" with required information.
2. System will assign a "Request Number" to the form and store it.
3. R&D Manager will receive a notification of a project request.
4. R&D Manager will approve or deny the request.
5. If denied, user will receive notification of the status and reason for denial. Workflow ends and form is stored for historical purposes.
6. If Approved, System will assign a new project number and send the user a notification of the approved status and the project number. 

Is there a way to do this in JIRA?

[Nic Brough -Adaptavist- · Accepted solution]

Yes.  I've done this loads of time

1.  I'd create an issue type of "project" (not request form or other convoluted names - it's going to be an object and record of the whole lifecycle, so it really is just a "project")
2. Request number = JIRA issue ID
3. Standard notification scheme stuff
4. You'd want to design a workflow that matches the business process.  So I'd have create -> waiting approval -> Active project -> closed project (note I'm planning for projects to end too)
5. Include and a "project refused" status for managers to say "no".  
6. Notification is the same as 3, the only sticking point is your "new project number".  You could keep it really simple and say "your project number is the JIRA issue ID".  Or with a bit of scripting or code, you could generate some other pattern.
7. The reason I've done this before and added a step to your process... I wrote code that created the project automatically when the manager approves.  That means your admins have the joy of doing absolutely nothing to support the process 

I'd try to catch other information about the project in custom fields as well, one good one might be project-owners (which can then be edited later), projected dates of project activity, and obviously all the detail on what type of project it is, the description you want, the type (development/scrum/operations/doc tracking/etc) the default users maybe, etc.  Another trick might be to require users to submit sub-tasks when they want to re-configure their projects, then you have a complete track of all your admin activities as well as a place to track your work on them.

[Erik Arendall]

I would need to create the issue under a project, whats your thoughts on that grouping and how have you handled that?

I would assume the best way is to keep the issues under a "R&D Projects" project and the individual issues be the projects under that. Kind of a parent project and all other projects under that are the children.

Thanks for your assistance.

[Nic Brough -Adaptavist-]

Absolutely per your assumption - I've always had either a "project register" project, or the project items have been a dedicated issue type inside a "jira support" type project. The first option is neater!