Product Bible - Deskely

Introduction

Deskely is a modern, web-based commissioning and inspection management system designed specifically for FPSO (Floating Production Storage and Offloading) projects. It supports the complete inspection and commissioning lifecycle, starting from preparation of master data and templates, through execution of inspections and walk-downs, to punch management and final certificate issuance.

Deskely introduces multiple inspection types, configurable templates, dashboard-style summaries, advanced filtering and export options, and reliable offline support through a mobile application.

The platform is designed to be used by inspectors, supervisors, commissioning teams, certification authorities and project managers, ensuring that all stakeholders can collaborate efficiently within a single system.

Purpose of the System

The main purpose of Deskely is to make inspection and commissioning work digital and easy to manage. It supports different inspection modules such as ITRs (Checksheets), Preservation Work Lists (PWL), Commissioning Procedures (CP), Walkdowns, Punches, and Certificates. Deskely helps users track inspections, punches, and approvals clearly and accurately. It shows real-time project progress so users can easily see what work is completed and what is still pending. The system supports a clear and structured sign-off process and reduces manual paperwork, which improves data accuracy. Deskely also ensures that inspections are performed using approved templates, all issues are properly tracked through the punch process, and certificates are generated only when all required inspections and acceptance conditions are successfully completed.

System Overview

Deskely consists of a web application and a mobile application, both connected to the same backend system.

Web Application

The web application is primarily used for:

• Configuration and setup (master data, templates, tag management etc)

• Monitoring progress through dashboards

• Reviewing and approving inspections

• Managing punches and certificates

• Exporting data for reporting

Mobile Application

The mobile application is designed for field use and supports:

• Offline execution of inspections

• Capturing photos and comments

• Raising punches on site

• Signing off inspections

• Synchronising data when internet connectivity is available

Deskely supports offline-first behaviour. Data entered in the app is stored locally and synchronised with the web system once the device is online.

Navigating Deskely

After logging into Deskely, users see a consistent layout across the system.

Main Navigation Menu

The left-hand sidebar contains the following main sections:

• Dashboard Provides a high-level overview of project status, key metrics and alerts.

• Field Work Includes all execution-related modules:

  • Checksheets (ITR)

  • Preservation Work List (PWL)

  • Commissioning Procedures (CP)

  • Walk-downs

  • Punches

  • Certificates

• Data Management Configuration and reference data modules:

  • Master Data

  • Tag Management

  • Checksheet Management

  • PWL Management

• Template Designer Used to design and manage templates for inspections, walk-downs and certificates.

• Administration Project, organisation, user roles and permissions management.

A global search bar is available at the top, allowing users to search across multiple modules without navigating away from the current page.

Deskely Core Concepts

Before using Deskely, it is important to understand these key concepts:

• Templates – Define the structure, fields, and workflow for Checksheets, Walkdowns, PWL, CP, and Certificates.

• Tags – Identifiers for equipment, instruments, valves, loops, or systems.

• Tag Sets – Logical groups of tags used to assign templates and records in bulk.

• Checksheets – Inspection forms created from templates and assigned to tags or tag sets.

• Walkdowns – Site verification records used to capture field observations and required actions.

• PWL (Preservation Work List) – Preservation records used to track equipment preservation activities over time.

• CP (Commissioning Package) – Records used to manage commissioning-related checks, approvals, and sign-offs.

• Certificates – Documents generated for verification/approval purposes as per project requirements.

• Inspection Records – Forms created from templates and used to record actual inspection results.

• Punches – Non-conformities or issues identified during inspections, checksheets, or walkdowns.

• Sign-offs – Role-based approvals that move records through each stage of the workflow lifecycle.

Data Management

The Data Management section in Deskely is used to maintain and manage the key data that supports the whole system. It works as the backbone of Deskely because all inspections and workflows depend on the data configured here. If the information in Data Management is missing or incorrect, it can cause issues in templates, tags, inspections, filtering, and reporting.

Data Management helps keep the system organised by storing structured information such as master records, tag-related details, and template assignments. It ensures that users can work with standard and consistent values across all modules like Checksheets (ITR), PWL. This also improves accuracy and reduces errors because users select values from predefined options instead of entering data manually.

Another important role of Data Management is supporting smooth workflow execution. When tags and templates are set correctly through Data Management modules, inspections are generated properly and appear in the relevant Field Work modules. This makes it easier for inspectors and supervisors to track work progress, complete activities, and perform sign-offs without confusion.

Overall, Data Management is essential for system setup, consistency, and long-term project control. It helps ensure that all modules work correctly, data remains traceable, and reporting is reliable throughout the project lifecycle.

Master Data

Master Data is the basic and reference information used across the Deskely system. It includes common values such as systems, sub-systems, disciplines, locations, phases, scopes, and other standard lists. Instead of entering this information repeatedly, Deskely uses Master Data so that users can select values from predefined options, keeping data consistent and accurate.

Master Data is important because it helps standardise information across the entire system. When everyone uses the same values, it becomes easier to manage inspections, generate reports, and track progress without confusion or data mismatch.

Why Master Data is Used

Master Data is used to avoid manual errors and maintain uniform naming throughout the system. It ensures that inspections, templates, and reports follow the same structure. This makes filtering, searching, and reporting reliable and meaningful for all users.

How Master Data is Created and Used

Users create Master Data entries from the Data Management section. Once entries are added, they automatically become available across Deskely. These values are then selected while creating tags, designing templates, and executing inspections.

For example, systems and disciplines created in Master Data are used in Tag Management, Template Designer, and inspection modules like Checksheets, PWL, CP, and Walk-downs. Certificates also rely on Master Data to group and generate system- and discipline-based certificates.

Importance of Master Data

Because Master Data is connected to almost every module, it should always be reviewed and finalised before starting large-scale template creation or inspection execution. Any change in Master Data can affect tags, templates, inspections, and certificates. This approach follows the same concept used in the CeMIC system, where master data is prepared first and then used throughout the inspection and commissioning process.

For detailed step-by-step usage of Master Data, please refer to the User Flow Guide and open the Master Data section.

Link: Master Data User Flow

ITR Template (Inspection Test Record)

An ITR Template (Inspection Test Record) is a ready-made inspection form used in Deskely. It explains what should be checked, what information must be filled, and who will approve the inspection. This helps make sure all inspections are done in the same correct way, instead of creating new forms manually every time.

An ITR template is like a sample or model form. It does not show the inspection results. It is later assigned to tags or tag sets to create the real inspection records that users will complete.

Purpose and Structure of ITR Templates

The main purpose of an ITR Template is to make sure inspections are done in a proper, consistent, and controlled way across the whole project. It helps ensure that every inspector follows the same approved format instead of doing inspections in different styles. This makes inspection work more organised and easier to track. ITR templates also help the project follow required standards, because inspections are performed according to the correct process and acceptance rules. Another important purpose of ITR templates is traceability, meaning the system can track who performed the inspection, what was checked, and who approved it through the sign-off workflow.

An ITR template also defines the full structure of the inspection form. It usually includes the inspection type, so users understand what kind of inspection is being performed. It contains the inspection content such as checks, measurement fields, remarks, and attachments, so users know exactly what information needs to be filled and what evidence needs to be added. It also includes a sign-off and approval workflow, which clearly defines who must sign and in what order. This ensures the inspection moves through the correct approval process and is completed only when all required sign-offs are done. This structured approach separates template design from inspection execution, which is the same core concept followed in the CeMIC system as well

Template Lifecycle and Versioning

ITR templates follow a controlled lifecycle. Templates are created and later published so they can be used in inspections. When changes are required, templates can be revised and republished, creating new versions. Older versions remain available for reference, ensuring traceability and audit history.

This version-based approach ensures that inspections already in progress are not affected by template changes, while new inspections always use the latest approved template.

For detailed step-by-step usage of Checksheets (ITR), please refer to the User Flow Guide and open the Checksheets (ITR) section.

Link : ITR User Flow

Flow After ITR Template Creation

After an ITR (Inspection Test Record) template is created and published, inspections do not start immediately.

In Deskely, inspections are always linked to tags, which represent actual equipment or items in the project. Because of this, the next step after ITR templates is Tag Management.

What is Tag Management and Why It Is Used

Tag Management is used to create and manage tags in the system. A tag is an ID for equipment, instruments, valves, loops, or systems. It helps users keep all project equipment data organized and easy to find.

With Tag Management, users can add tags, update tag information, and link tags with templates, checksheets, PWL, and punches etc. This also helps in traceability, which means the system can track what work was done on each tag and who completed or approved it.

Creating a New Tag

In Deskely, a Tag is used to represent a real equipment item in the project, such as a pump, valve, instrument, panel, or any other component that needs inspection or commissioning. Tags are very important because Deskely tracks all inspection and workflow progress using tags. Without creating tags, inspections cannot be assigned or executed properly.

In the Tag Management module, users can create a new tag by entering the required tag information. While creating a tag, the user also assigns important details such as System, Sub-System, Discipline, and Location. These values are selected from Master Data, which helps keep the naming and structure consistent for the entire project. This consistency is useful because it prevents mistakes, improves reporting, and makes filtering easier across different modules.

Once a tag is created, it becomes available in the system for inspection activities. This means templates such as ITR (Checksheets) can be assigned to the tag based on project requirements. After assignment, the related inspection records can be generated, tracked, and completed through the correct workflow and sign-off process.

In simple words, creating a tag means the equipment is successfully added to Deskely and is now ready to be inspected, tracked, and included in project progress and reporting.

Assigning an ITR Template to a Tag

After the tag is created, the next step is to assign an ITR template to that tag (or to a tag set, if it applies to multiple tags). This is an important step because it connects the inspection template with the real equipment in the system.

When the ITR template is assigned, Deskely understands that this specific equipment tag must follow that inspection format. The system now knows what checks and fields should appear when the inspector opens the inspection form.

This assignment also defines which workflow and sign-off process will be used. It controls who can fill the inspection, who will review it, and who will approve it. In simple words, assigning the template means the inspection is now linked to the equipment and is ready to be generated and used in the Checksheets module.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Tag Management” section to learn more details about this process.

Link: ITR Tag Management

Role of Checksheet Management

After an inspection template is assigned to a tag, Deskely uses Checksheet Management to handle and manage this connection. This module helps make sure the correct template is linked to the correct tag and everything is set properly before inspection work starts.

Checksheet Management keeps a clear record of which tag is connected to which template. Because of this, Deskely can generate the correct inspection form automatically and show it in the Checksheets module. It also helps control how inspections appear in the list and makes sure the workflow stays organised.

In simple words, Checksheet Management works like a bridge between templates and actual inspections, so inspections are created correctly and can be tracked easily in the system

Overall Process Flow

First, an ITR template is created and published in the Template Designer. After that, an equipment tag is created in the Tag Management module so the equipment is available in the system. Then the ITR template is assigned to the tag, which connects the inspection form with that equipment. After the template is assigned, Deskely manages this connection in Checksheet Management to make sure the correct mapping is saved. Finally, the inspector opens the record from the Checksheets module and performs the inspection by filling the required details, adding attachments, and completing sign-off when all requirements are done.

Checksheet Management

Checksheet Management is the module where we assign inspection templates to tags or tag sets. After we create and publish an ITR template, it is not used directly in inspections. First, we connect that template with real equipment tags. This is done in Checksheet Management.

This module helps make sure the right template is attached to the right tag, so inspections can be performed correctly.

Flow After Template is Published

After publishing a template, we go to Tag Management / Checksheet Management and apply the template to a tag. When the template is assigned, Deskely creates the related checksheet automatically. Then the checksheet appears in the Checksheets module where inspectors can start inspection work.

So, Checksheet Management works like a connection between Template Designer and the inspection forms

Edit Options in Checksheet Management

In Checksheet Management, we can edit only a few important fields:

• Is Paper – This is used when the checksheet inspection is done on paper instead of the system.

• Phase – This shows the inspection phase (like pre-commissioning, commissioning, etc.).

• Scope – This shows the inspection scope or area of work.

These fields help set the correct inspection information.

Review, Issue, and Void

From Checksheet Management, we can review and issue the checksheet. When a checksheet is issued, it becomes ready for inspectors to use.

If a checksheet is not needed or was assigned wrongly, we can void it. A void checksheet is not used anymore, but it stays in the system for record purposes.

Why Checksheet Management is Important

Checksheet Management is important because it helps keep the inspection process correct and organised. It connects inspection templates with real equipment tags, so the right checksheet is created for the right equipment. It also helps manage inspections in a controlled way by supporting actions like review, issue, and void. This keeps the workflow clear and ensures inspection data stays clean, accurate, and easy to track in the system

For step-by-step guidance, please refer to the User Flow Guide. Open the “Checksheet Management” section to learn more details about this process.

Link: Checksheet Management

Checksheets Module (After Checksheet Management)

After Checksheet Management, the next step is the Checksheets module. In this module, users can view all checksheets that have been issued and are ready for inspection work.

In the Checksheets module, checksheets are shown based on their current status, such as Unopened, In Progress, Under Sign-off, Completed, and other available status categories. This helps users quickly understand which checksheets are pending and which ones are already completed.

Each checksheet record also has an Actions menu. From the Actions menu, users can open the checksheet using the View option. Inside the checksheet, users can access important sections such as Details, Activities, and Pictures. Users can also add attachments, update required information, and complete the inspection work.

Once all required fields, attachments, and inspection steps are completed, the user can proceed with the Sign-off process. Sign-off is only allowed when all requirements are fulfilled, and it moves the checksheet to the next stage in the workflow.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Checksheets” section to learn more details about this process.

Link: Checksheets

PWL Template (Preservation Work List)

A PWL Template (Preservation Work List) is a predefined format used in Deskely to standardise preservation activities for equipment and systems. It defines what preservation tasks need to be performed, what information must be recorded, and how approvals and sign-offs will be handled. Instead of creating preservation forms manually each time, Deskely uses PWL templates to ensure preservation work is done in a consistent and controlled way.

A PWL template represents the preservation requirement, not the final result. It acts like a blueprint that is later assigned to tags or tag sets to create actual PWL records.

Purpose and Structure of PWL Templates

A PWL Template is used to ensure that preservation work is consistent, properly documented, easy to track and manage, linked with equipment tags for full traceability, and approved through the required sign-off workflow. It helps teams maintain equipment condition before and during commissioning, especially for items that require preservation over time. A PWL Template usually defines the preservation tasks or checklist items, required fields such as remarks, dates, and evidence, attachments or photos (if required), and the sign-off workflow showing who must approve the preservation activity, ensuring that every preservation record follows the same structure across the project.

PWL Template Lifecycle and Versioning

PWL templates follow a controlled lifecycle in Deskely. Templates are created, designed, and then published so they can be used for actual preservation work. When changes are needed, templates can be updated and republished, creating a new version.

Older versions remain available for reference, so the system keeps a proper history and does not affect records that are already started.

If updates are required, a PWL template can be edited and republished. Republishing ensures that the changes are applied correctly and new records use the latest version. This helps avoid confusion and keeps preservation work aligned with updated requirements.

For step-by-step guidance, please refer to the User Flow Guide. Open the “PWL” section to learn more details about this process.

Link: PWL User Flow

Flow After PWL Template Creation

After a PWL (Preservation Work List) template is created and published, preservation activities do not start immediately.In Deskely, preservation records are always linked to tags, which represent actual equipment or items in the project. Because of this, the next step after creating a PWL template is Tag Management.

Creating a New Tag

In Deskely, a Tag represents a real equipment item in the project such as a pump, valve, instrument, panel, or any other component that needs preservation or follow-up. Tags are very important because Deskely tracks all preservation and workflow progress using tags. Without creating tags, PWL records cannot be assigned or managed properly.

In the Tag Management module, users can create a new tag by entering the required tag information. While creating a tag, the user also assigns important details such as System, Sub-System, Discipline, and Location. These values are selected from Master Data, which helps keep the naming and structure consistent for the entire project. This consistency helps reduce mistakes, improves reporting, and makes filtering easier across different modules.

Once a tag is created, it becomes available in the system for preservation activities. This means templates such as PWL can be assigned to the tag based on project requirements. After assignment, the related PWL records can be generated, tracked, and completed through the correct workflow and sign-off process.

In simple words, creating a tag means the equipment is successfully added to Deskely and is now ready to be preserved, tracked, and included in project progress and reporting.

Assigning a PWL Template to a Tag

After the tag is created, the next step is to assign a PWL template to that tag (or to a tag set, if it applies to multiple tags). This is an important step because it connects the preservation template with the real equipment in the system.

When the PWL template is assigned, Deskely understands that this specific equipment tag must follow that preservation format. The system now knows what checks and fields should appear when the user opens the PWL form.

This assignment also defines which workflow and sign-off process will be used. It controls who can fill the PWL record, who will review it, and who will approve it. In simple words, assigning the template means the preservation record is now linked to the equipment and is ready to be generated and used in the PWL module.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Tag Management” section to learn more details about this process.

Link: PWL Tag Management

PWL Management (Preservation Work List Management)

After creating and assigning PWL Templates, the next step is to manage them from the PWL Management module. This module is mainly used to update and control preservation-related settings for each tag. It helps the team make sure that the correct preservation information is saved before the actual preservation work starts. In simple words, PWL Management is the place where we confirm the PWL setup and schedule for a tag.

In Deskely, PWL Management works on Tags only. This means that PWL Management does not follow the TagSet concept. Each PWL record is handled individually for a tag, so users can edit and update preservation settings tag-wise according to project requirements.

When the user opens Data Management → PWL Management, they can view the list of tags that have PWL assignments. From the actions menu, the user can open a specific record to update it. Once the record is opened, an “Update PWL” modal appears. This modal usually has two steps: the first step is the main PWL update screen, and the second step is Review & Issue, where the user confirms the details before finalizing.

Inside the Update PWL screen, the user can update important fields such as Is Paper, PWL Discipline, PWL Phase, and Scope. These fields help define the type of preservation work and how it will be tracked. The user can also update scheduling details like Due Date, End Date, Routine Period, and Routine Days. These scheduling fields are important because they decide when preservation activities should start, when they should end, and how frequently they need to be performed.

Some fields in the form have a red asterisk (*), which means they are mandatory. If the user leaves any mandatory field empty, the system should show a validation message and should not allow the process to continue until the required information is filled properly. This ensures that the PWL data remains complete and accurate.

After entering the correct details, the user can click Next to go to the Review & Issue step, or click Save & Close to save the updated information. If the user does not want to save changes, they can click Cancel to close the modal without updating anything.

Overall, PWL Management is important because it helps maintain correct preservation settings and schedules for each tag. It ensures that the preservation tasks are properly planned, tracked, and executed according to the project workflow, so the team can easily monitor progress and avoid missing important preservation activities.

For step-by-step guidance, please refer to the User Flow Guide. Open the “PWL Management” section to learn more details about this process.

Link: PWL Management

Preservation Work List (PWL) Module

After completing the setup in PWL Management, the next step is to move to the Preservation Work List (PWL) module under the Field Work section. This module is used to view and perform the actual preservation work on tags. It works very similar to the Checksheets module, because here also users can track forms by status, open a form, fill activities, add evidence, and complete sign-off when everything is done.

When the user opens the PWL module, they can see a dashboard-style screen where PWL records are shown in a list. The page also shows status cards (or summary counts), which help users quickly understand how many PWL forms are pending or completed. Users can also use the search bar to find any tag easily, and apply filters to view forms based on phase, scope, discipline, or status. This makes it easy to manage a large number of preservation records.

Inside the PWL table, every form has a status such as Unopened, In Progress, Rejected, Awaiting Approval, or Completed. These statuses help the team understand the current progress of preservation work. Users can open any PWL form from the Actions menu and view its complete details.

After opening a PWL form, the user can go through different tabs like Details, Activities, Pictures, Punch List, Attachments, and Sign. In the Activities section, the user fills the required preservation checks according to the template. If pictures or attachments are required, the user can add them as evidence. If any issue is found during preservation, the user can also create or view punches from the Punch List tab.

Once all required information is completed, the user can move to the Sign tab and perform sign-off according to the workflow. Sign-off is only possible when all mandatory requirements are fulfilled, such as completing activities and adding required attachments if needed. After successful sign-off, the PWL status moves forward in the workflow until it finally becomes Completed.

Overall, the PWL module is the main place where preservation work is executed, tracked, and completed. It provides a clear workflow similar to Checksheets, so users can easily monitor preservation progress and ensure all required preservation tasks are performed properly before the system moves to later stages like certificates.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Preservation Work List” section to learn more details about this process.

Link: Preservation Work List

CP Template

CP Templates are used to define commissioning steps and procedures in a structured way. These templates act as a standard format that will later be used to create CP records for execution and sign-off. Users go to CP Templates inside the Template Designer section and create a new CP template by entering basic template information such as title and setup details.

After that, users configure the sign-off workflow, which defines who will approve the CP and in what order. Then, the template is designed by adding required sections, steps, and fields that will be filled during commissioning execution. Once the design is completed, the template can be published, making it available in the system. However, after publishing, there is currently no republish option for CP templates, and CP templates also do not maintain multiple versions or version history.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Cp Templates” section to learn more details about this process.

Link: CP Templates

Commissioning Procedures (CP) Module

After the CP template is created and published, the next step is to move to the Commissioning Procedures (CP) module inside the Field Work section. This module is used to view and execute the actual commissioning procedures that are assigned in the system. In this module, procedures are usually divided into phases such as Pre-Commissioning, Commissioning, and Post-Commissioning, and it also shows different statuses like Unopened, In Progress, Under Sign-off, Rejected, or Closed.

When a user opens a procedure, they can view complete information in sections like Details, Activities/Steps, Attachments, and Sign-off. Users complete the required steps, record results, and upload attachments if needed. Once all steps and required information are completed, the user proceeds to the sign-off process, which follows the workflow defined in the CP template, and the procedure moves through approvals until it becomes Closed. This ensures commissioning procedures are completed properly with correct documentation and required approvals.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Commissioning Procedure” section to learn more details about this process.

Link: Commissioning Procedure

Walkdowns Overview

Walkdowns in Deskely are used to perform structured inspections and track readiness at different levels of the project. Deskely includes five Walkdown types: MLP, G03, G05, G07, and G08. Each type is automatically created based on specific project data rules, so walkdowns remain organised and consistent across the system.

How Walkdown Templates Are Created

Walkdown templates are automatically created when relevant entries are added in Master Data (such as system, subsystem, discipline, location, or project-related records). Users do not create walkdown templates manually. Once templates are created, users can configure them by adding sign-offs and publishing them.

MLP Walkdowns (Based on Location)

MLP walkdowns are created based on Location. This means that when locations exist in master data, Deskely generates walkdown templates and records according to those locations. MLP helps track inspections location-wise to ensure readiness checks are completed properly.

G03 Walkdowns (Based on Subsystem + Discipline)

G03 walkdowns are created based on Subsystem and Discipline. This type uses both values together, which allows more detailed walkdown structure. It helps teams track walkdown progress for specific subsystems within a particular discipline.

G05 Walkdowns (Based on Subsystem)

G05 walkdowns are created based on Subsystems only. This type groups walkdown records by subsystem, which helps teams focus on readiness and inspection progress for each subsystem without discipline separation.

G07 Walkdowns (Based on System)

G07 walkdowns are created based on the System. This type is used to manage walkdown inspections at a higher level, where the focus is on system-wise readiness and completion tracking.

G08 Walkdowns (Based on Project Level)

G08 walkdowns are created based on the Project level. This type is used for project-wide walkdown tracking and is not tied directly to location, subsystem, or system in the same way as the other types.

Publishing and Using Walkdown Templates

After walkdown templates are generated, users can add sign-off settings and then publish the templates. Once sign-offs are added and the template is published, the walkdown template becomes ready for use in the Walkdowns module.

This ensures walkdowns follow the correct workflow and can be executed and tracked properly across the project.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Walkdowns Template” section to learn more details about this process.

Link: Walkdowns Template

Walkdowns Module

After walkdown templates are published and sign-offs are set, the next step is to use the Walkdowns module in the Field Work section. In this module, users can view, manage, and complete walkdowns based on different project levels. Deskely shows walkdowns in five separate types: MLP, G03, G05, G07, and G08. Each type has its own tab, and users can open each walkdown record, perform activities, add remarks and pictures, and complete sign-off when requirements are fulfilled.

MLP Walkdowns (Location-based)

In the MLP tab, walkdowns are organised based on Locations. This helps inspectors and teams track walkdown progress location-wise. Users can open any MLP walkdown record from the list and view its details. Inside the record, users can complete activities, add required information, upload pictures, and record findings. Once everything is completed, the walkdown can be moved forward through sign-off.

G03 Walkdowns (Subsystem + Discipline-based)

In the G03 tab, walkdowns are organised based on Subsystem and Discipline. This allows more detailed tracking because the walkdown record represents a specific subsystem within a discipline. Users can open the record, review the inspection requirements, and complete activities according to the template. Pictures and remarks can be added as evidence, and sign-off can be completed once the walkdown meets all requirements.

G05 Walkdowns (Subsystem-based)

In the G05 tab, walkdowns are grouped based on Subsystem only. This helps users monitor subsystem readiness without dividing it by discipline. The workflow remains similar: users open a walkdown record, complete activities, add supporting pictures, and move the record through sign-off stages after completion.

G07 Walkdowns (System-based)

In the G07 tab, walkdowns are managed based on System. These walkdowns give a higher-level view because the record represents an overall system inspection. Users can open the record, verify details, complete checklist activities, and add evidence. After completion, sign-off is performed as per the defined workflow.

G08 Walkdowns (Project-based)

In the G08 tab, walkdowns are organised at the Project level. This type is used to track walkdown progress at a broader level. Users can open project-level walkdown records, review the required checks, complete activities, attach pictures, and proceed with sign-off when ready.

Common Features in All Walkdown Types

All walkdown types follow a similar execution flow inside the record. Users can view the walkdown Details, perform required Activities, upload Pictures/Attachments, and complete Sign-offs based on the workflow. Walkdowns also support tracking of issues and progress, helping teams understand which walkdowns are pending and which are completed.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Walkdowns ” section to learn more details about this process.

Link: Walkdowns

Punches Flow

In Deskely, Punches are issues or non-conformities that are created during inspections and field activities. Punches are created/added from the App, and also they are managed on the Web.

How Punches Are Created

Punches can be created in two ways:

• Manual Punches - These punches are created manually by the user from the App.

• Automatic Punches - These punches are generated automatically by the system during use of the punch trigger option.

Once punches are created from the App, they start appearing in the Punches module.

Punches Categories

After creation, punches can be found in these categories:

• Unapproved

• Approved

• Deleted

Unapproved to Approved Flow

Punches remain in the Unapproved section until the related record is completed. When ITR, PWL, CP, or Walkdown records are signed-off, their related punches automatically move from Unapproved to Approved.

Deleted Punches

If a punch is deleted, it is moved to the Deleted section.

Punch Closing and Reopen Process

• Clears the punch from the App

• Then Closes or Reopens the punch from the Web

This helps in managing punch status properly.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Punches ” section to learn more details about this process.

Link: Punches

Certificates Overview

The Certificates module in Deskely is used to generate and manage project certificates that confirm inspection and commissioning completion for systems and equipment. Certificates are an important project milestone because they show that the required inspections, procedures, and checks have been completed successfully according to project standards. Deskely supports different certificate types, and each type represents a specific acceptance stage, so teams can track progress clearly and maintain proper project readiness.

How Certificate Templates Are Created

Certificate templates in Deskely define the structure, workflow, and sign-off requirements for certificate records. These templates help ensure that all certificates follow a standard format and the correct approval process. Once the certificate template is ready, it can be published so it becomes available for use in the Certificates module.

Certificate – Based on Sub System and Discipline

In Deskely, G03 Certificates are created based on Sub System and Discipline. This means the G03 certificate structure depends on the combination of these two master data values.

When a new Sub System and new Discipline are created in Master Data, Deskely uses this information to organize the G03 certificate flow. After that, when a related Checksheets (ITR) is issued using that Sub System and Discipline, the system then generates the G03 Certificate for that issued checksheet.

In simple words, G03 Certificate is created only when the required Sub System + Discipline exists in Master Data and a checksheet is issued against it. This ensures certificates are generated in a controlled and structured way, based on real project inspection activity.

G05 Certificate – Based on Sub System

In Deskely, G05 Certificates are created based on the Sub System. This means the G05 certificate structure depends on the selected Sub System.

When a new Sub System is created in Master Data, Deskely uses this information to manage the G05 certificate flow. After that, when a related Checksheets (ITR) is issued using that Sub System, the system generates the G05 Certificate for that issued checksheet.

In simple words, G05 Certificate is created when the required Sub System exists in Master Data and a checksheet is issued against it.

G06 Certificate – Based on Sub System

In Deskely, G06 Certificates are created based on the Sub System. This means the G06 certificate structure depends on the selected Sub System.

When a new Sub System is created in Master Data, Deskely uses this information to manage the G06 certificate flow. After that, when a related Checksheets (ITR) is issued using that Sub System, the system generates the G06 Certificate for that issued checksheet.

In simple words, G06 Certificate is created when the required Sub System exists in Master Data and a checksheet is issued against it.

G07 Certificate – Based on System

In Deskely, G07 Certificates are created based on the System. This means the G07 certificate structure depends on the selected System.

When a new System is created in Master Data, Deskely uses this data to manage the G07 certificate flow. After that, when a related Checksheets (ITR) is issued using that System, the system generates the G07 Certificate.

In simple words, a G07 Certificate is created when the required System exists in Master Data and a checksheet is issued against it.

G08 Certificate – Based on Project

In Deskely, G08 Certificates are created based on the Project. This means the G08 certificate structure depends on the overall project level setup.

When the Project is available and configured in the system, Deskely uses it for the G08 certificate flow. After that, when a related Checksheets (ITR) is issued at the project level, the system generates the G08 Certificate.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Certificates Template ” section to learn more details about this process.

Link: Certificates Template

Certificates Module

In Deskely, the Certificates Module is used to manage certificate records through different statuses. Users can open certificates, issue them, view details, download documents, and perform required actions based on the certificate status and sign-off setup.

Not Started (Actions: Issue & Download)

When you open the Certificates module, go to the Actions column. For certificates in Not Started status, two actions are available:

• Issue

• Download

Important: The Issue action will remain disabled until sign-offs are added in the certificate template. Once sign-offs are added in the template, the Issue action becomes enabled, and the user can issue the certificate.

Ready for Issue (Actions: View, Issue & Download)

After issuing the certificate, it moves to Ready for Issue status. In this status, the Actions menu shows:

• View

• Issue

• Download

Users can click View to open the certificate and see all the information and details.

In Progress (Actions: View & Download)

After issuing, the certificate then moves to In Progress. In this status, the Actions menu shows:

• View

• Download

Users can view the certificate record and continue working on it as required.

Completed (Actions)

Once the certificate is completed, it appears in Completed status. In this status, the Actions menu shows the following options:

• View

• Reissue

• Reopen

• Versions

• Complete Partial

• Download

View Action

When the user clicks View, the certificate record opens and shows complete details. Inside the certificate, users can view the Certificate Details and Activities section. Only the user who has the first role in the sign-off workflow can fill or answer the activities. Users can also add attachments if required and perform sign-offs based on their permissions. In addition, the certificate record displays the linked ITR List and Punch List, which helps ensure that the certificate is completed with proper information, evidence, and approvals before it is finalized.

For step-by-step guidance, please refer to the User Flow Guide. Open the “Certificates ” section to learn more details about this process.

Link: Certificates