JCOR

Cloud System Request Management

System Requests

No requests found.

New System Request

Customer: Contract:

No matches

1-9 lowercase alphanumeric

Auto-filled from HubSpot

Cloud & Infrastructure

Convention: tmppub{customer}{region}jivs Convention: tmp{customer}jivs (3-24 lowercase alphanumeric)

Est. Monthly Cost

/mo

VM
Data Disk
Extra Disks
OS Disk

Extra Disks

No extra disks. Click "Add Disk" to add one.

NSG Rules Network Security Group rules control inbound/outbound traffic. Define source IP, port, and protocol for each rule.

No NSG rules defined.

Firewall IPs

No firewall IPs defined.

Access Controls

VPN was auto-enabled by Application Server. IP address can be added later during onboarding.

Encryption & Protection

Password Policy

Monitoring & Backup

Maintenance & Documentation

Technical Consultants

At least one consultant is required for new system requests.

No consultants added. Click "Add Consultant" to add one.

Admin Settings

Help & Documentation

Getting Started Creating Requests Private Cloud & Sizing Status Workflow Roles & Permissions FAQ

Getting Started

JCOR is the cloud system request management tool for DMI. It replaces the legacy JCOB application and uses GitHub Issues as its backend storage.

How to sign in: Click "Sign in with Microsoft" on the login page. Use your Microsoft (Entra ID) account. If you've been invited as a guest, accept the invitation email first.

Navigation: Use the top menu to switch between views:

  • Requests — View and filter all cloud system requests
  • + New Request — Create a new cloud system request
  • Settings — Admin-only configuration (webhooks, labels)
  • Help — This page

Creating Requests

A request describes a cloud system that needs to be provisioned, extended, or decommissioned. The form is organized in tabs:

Core

Customer selection (HubSpot search or existing request), contract number, customer code (Azure identifier), cloud type, region, and system details.

Infrastructure

Storage accounts, extra disks, database requirements, backup retention, and VPN configuration.

Security

NSG (firewall) rules, SIEM/log analytics configuration, and compliance requirements.

Operations

JiVS version, source DB size, system landscape, start/end dates, monitoring, and Private Cloud flags (RM, AS).

Consultants

Assign technical consultants who will work on the system. Each consultant has a name, email, and role.

Request Types:

  • New System — Provision a new cloud VM. Select customer from HubSpot (searchable dropdown), contract number and customer code are auto-filled.
  • Extension — Modify an existing system. Select from existing requests - customer and contract data are pre-filled.
  • Decommission — Shut down an existing system. Select from existing requests.

Customer & Contract Fields:

  • Customer — Full name from HubSpot CRM (e.g. "Acme Corporation")
  • Customer Code — Short Azure identifier (1-9 lowercase alphanumeric, e.g. "acme"). Auto-derived, editable. Used for VM naming and storage accounts.
  • Contract Number — From HubSpot. If a customer has multiple JiVS installations, a dropdown lets you pick the right contract.

Duplicate Detection: For Public Cloud new systems, JCOR checks if a VM with the same name already exists for that customer and will warn you.

Email Notifications: When a request's status changes, email notifications are automatically sent to the requester, assigned consultants, and any additional recipients configured in Admin Settings. Emails are sent via SMTP (configurable by Admin).

Private Cloud, Sizing & VPN

Private Cloud systems support two additional workload flags that affect infrastructure sizing and VPN requirements.

Application Server (AS)

Enable when the customer has a SAP Application Server that accesses the JiVS database directly. This:

  • Automatically enables IPSec VPN
  • Makes the IP address field optional (can be provided during onboarding)
  • Increases the sizing tier due to additional network I/O

Retention Management (RM)

Enable when the system runs periodic batch SQL on history databases for data retention policies. This:

  • Requires higher CPU and disk I/O performance
  • Increases the sizing tier significantly
  • Combined with AS, triggers maximum tier (Dragon)

Sizing Advisor (Animal Tiers):

Source DB Size No Flags RM or AS RM + AS
< 500 GBRabbitWolfBear
500 GB - 2 TBWolfBearDragon
> 2 TBBearDragonDragon

VPN & IP Address:

Scenario VPN IP Address
Manual VPN (no AS)User enablesRequired
AS-triggered VPNAuto-enabledOptional - provide during onboarding

Source DB Size: Enter the uncompressed size of the source database. Documents/ADK are entered as a combined value. JiVS compresses data during import, so actual disk usage will be lower than this number.

Note: The sizing advisor recommends a VM and disk type, but processors can override the selection. The price calculator shows estimated monthly CHF costs for budgeting purposes.

Status Workflow

Each request follows a defined lifecycle. Only authorized roles can advance the status.

New Approved In Progress Deployed Productive Decommissioned
New Rejected New (re-open)
Transition Required Role
New → ApprovedOrderManager or Admin
New → RejectedOrderManager or Admin
Approved → In ProgressOrderProcessor or higher
In Progress → DeployedOrderProcessor or higher
Deployed → ProductiveOrderProcessor or higher
Productive → DecommissionedOrderProcessor or higher
Rejected → NewOrderProcessor or higher

Roles & Permissions

Your role determines what actions you can perform. Your current role is shown in the top-right corner.

Action Requester Processor Manager Admin
Create requests✓✓✓✓
View all requests✓✓✓✓
Add comments✓✓✓✓
Change status—✓✓✓
Approve / Reject——✓✓
Assign consultants—✓✓✓
Update requests—✓✓✓
Terraform export———✓
Manage webhooks———✓

Frequently Asked Questions

Where is the data stored?

All requests are stored as GitHub Issues in the ops-terraform-hosting repository. Each request has structured labels and a JSON body that can be consumed by CI/CD pipelines.

What is the Storage Account field?

The storage account name is auto-derived from the customer name, cloud type, and region following DMI naming conventions. You can override it if needed.

Can I edit a request after submitting it?

Requesters cannot edit after submission. OrderProcessors, OrderManagers, and Admins can update any request via the detail view. Add a comment if you need changes made.

What happens when a request is approved?

An OrderManager or Admin moves the request to "Approved" status. The operations team then picks it up, assigns consultants, and moves it to "In Progress" when work begins.

Can all users see all requests?

Yes. All authenticated users can view all requests. This allows project managers to take over projects from colleagues when needed.

How does the Terraform export work?

Admins can export a request as a Terraform-compatible JSON file via the detail view. This JSON conforms to the ops-terraform-hosting schema and can be used directly in the provisioning pipeline.

Where do customer names come from?

For new systems, customers are loaded from HubSpot CRM (filtered by type=Customer, contract_type=SaaS). The searchable dropdown auto-fills the contract number and derives a short "Customer Code" for Azure naming. For extensions and decommissions, you select from existing requests.

Will I receive email notifications?

Yes, if SMTP is enabled by an Admin. When a request's status changes, an email is sent to the requester, all assigned consultants, and any additional recipients configured in Admin Settings.

I received a guest invitation but can't log in.

Make sure you accepted the invitation email first. Then sign in with your organization's Microsoft account. If issues persist, contact the DMI admin team.