Platform Guide

How to use CoreYard efficiently

CoreYard works best when data is loaded in the right order. Start with organization and project structure, then load holes and assets, use the map to verify spatial data, and move into CoreYard logging and operational workflows once the register is stable.

Recommended setup order

Follow this sequence to avoid rework and missing links between records.

Start with Team
Step 01

Create or choose your organization

Team
Open

Everything in the app is scoped to an organization first. If the user is still in the demo org, they should create or join their real org before loading production data.

Required first
Organization membership
User role
Creates
Active org selected
Admin/member access confirmed
Step 02

Create the project and set the CRS

Projects
Open

Projects are the parent records for holes and assets. The coordinate reference system should be configured here before loading any projected locations.

Required first
Organization
Project name
Creates
Project record
Coordinate CRS code or name
Optional dates, cost code, WBS
Step 03

Add supporting reference data

Projects and setup pages
Open

Before field data starts arriving, set up the supporting records that downstream workflows expect to reference.

Required first
Project exists
Creates
Tenements
Asset locations
Asset types
Resources
Vendors
Activity and PLOD types when needed
Step 04

Load holes and assets into the project

CoreYard and Map
Open

Holes and assets should be attached to a project as early as possible. That keeps mapping, logging, scheduling, and reporting aligned.

Required first
Project
CRS if using projected coordinates
Creates
Hole register
Mapped assets
Project-linked field records
Step 05

Use the map to verify and work spatially

Map
Open

Once holes and assets have coordinates, the map becomes the fastest way to inspect records, move locations, create new spatial records, and jump into CoreYard.

Required first
Hole collar longitude and latitude, or asset longitude and latitude
Creates
Verified spatial layout
Filtered project views
Map-driven record access
Step 06

Run CoreYard workflows

CoreYard
Open

CoreYard is where users manage holes, logging, dispatch, and core task progress. This area should be used after the project and hole register are in place.

Required first
Project-linked holes
Creates
Updated hole attributes
Logging progress
Dispatch records
Core task progress
Step 07

Capture operations, consumables, and schedule

Activity, Consumables, Scheduler
Open

Operational workflows become reliable after org, project, hole, and resource structures are already in place.

Required first
Resources
Vendors
Projects
Holes
Activity types where relevant
Creates
PLODs
Consumable tracking
Scheduled drilling tasks

What data needs to exist, and in what order

This is the practical dependency chain taken from how the app loads records today. If users populate data out of order, they usually feel it first in the map, CoreYard, and scheduling flows.

Organization

Team
Why: Controls access and data ownership.
Needed before: Everything

Projects

Projects
Why: Parent record for holes and assets.
Needed before: Holes, assets, map workflows, CoreYard work

Coordinate system

Projects
Why: Needed before importing projected easting and northing values.
Needed before: Bulk hole loading, mapped asset loading

Holes

CoreYard
Why: CoreYard, scheduling, drillhole viz, and map all depend on the hole register.
Needed before: Logging, dispatch, drillhole viz, scheduler, most drilling workflows

Assets

Map and assets workflows
Why: Required for mapped equipment, operational context, and some field actions.
Needed before: Asset map use, asset-linked activity capture

Resources and vendors

Setup and operational pages
Why: Required for scheduling and operational cost capture.
Needed before: Scheduler, realistic PLOD logging

Core task types and progress

CoreYard
Why: Used to record logging and core-processing progress against holes.
Needed before: Detailed core task tracking and dispatch readiness

PLOD activity types and rates

Operational setup
Why: Needed before users can capture consistent daily operational cost inputs.
Needed before: Reliable PLOD pricing and cost outputs

Fast path for a new real-world rollout