Setting Up Integration Server¶
This article describes the operational setup of Rillsoft Integration Server for administrators and IT owners. It complements the conceptual article Integration Server.
The main goal is not only to make the server technically available. The setup must create a reliable structure for tenants, resource pools, directories, users, permissions, projects, and optional modules such as DMS.
Prepare The Operating Model¶
Clarify these decisions before creating productive data:
which business unit, site, or company is represented by each tenant
who owns and maintains the central resource pool
how projects should be grouped in directories
which planners, resource managers, PMO users, and employees need access
which functions belong to Rillsoft Project and which belong to the web modules
whether DMS, time recording, vacation planning, or project import are part of the rollout
A poor initial structure is difficult to repair later because projects, permissions, and documents start to depend on it.
Create Tenants¶
A tenant is the base unit for resource pool, project directories, permissions, and documents.
Create a separate tenant when different organisational units need clearly separate resource pools or project data, for example separate companies, major sites, or business units with independent planning.
Each user needs explicit tenant access. Tenant access alone is not sufficient for productive work; users also need the required user roles and directory roles.
Design Directories¶
Directories organise projects and portfolios. They are virtual structures in the server database and should follow planning responsibility, not local file habits.
Useful directory structures include:
department or site
customer or project category
project phase
active, planned, archived, or template areas
PMO responsibility area
Keep the structure simple enough that users can predict where a project belongs. Too many levels increase permission errors and make portfolio work harder.
Set Up Roles And Permissions¶
Separate general rights from directory access:
- User roles
Define system-wide capabilities such as reading the resource pool, administering users, editing DMS documents, or using additional modules.
- Directory roles
Define what a user may do in a specific project directory, for example read, edit, delete, or manage projects.
Start with role groups that match real work:
project planner
resource manager
PMO
management read-only
employee feedback user
IT administrator
Avoid giving broad administrator rights to normal planning users. If everyone can edit everything, the server becomes a shared file store instead of a controlled planning system.
Prepare The Resource Pool¶
The resource pool is the most important data foundation for Rillsoft Project. Before productive migration, clean up:
employees and teams
roles and professional qualifications
calendars, working times, and non-working days
machines, machine types, material, and other shared resources
naming conventions for roles and teams
Capacity balancing is only meaningful when resource supply is current and resource demand is planned consistently. In many organisations, this means planning activities first by role or qualification and assigning named employees later.
Migrate Projects Gradually¶
Do not move all local project files to the server in one step. A controlled migration usually works better:
Clean up the resource pool and roles.
Create tenants, directories, and permissions.
Migrate a small pilot set of projects.
Check opening, saving, locking, versions, and portfolio views.
Validate capacity balancing and project controlling.
Migrate further projects in batches.
Keep the parallel phase short. If the same project exists both as a local file and as a server project, users can easily work on the wrong version.
Configure DMS If Required¶
If project documents are managed in Rillsoft Integration Server, define the DMS folder structure before users start adding files.
Decide:
which document folders exist for a tenant
who may read, create, update, delete, and restore documents
how document versions are handled
whether file size limits are required
which documents belong to projects, subprojects, or activities
Operational Checklist¶
Before go-live, verify:
users can log in and see only their authorised tenants
the resource pool opens and can be edited by responsible users
project planners can create, open, save, and lock projects
read-only users cannot modify project data
project versions can be recovered
DMS permissions match the intended document process
backup and restore procedures are defined
users know when to use server projects instead of local files