Introduction to Civillo permits

Civillo permits are designed to simplify and optimize the management of paper-based permit systems. It offers a robust templating system that allows organizations to create and customize permits according to their specific requirements. Some of the key features are:

1. Templating system The Civillo permits templating system enables users to design and modify permit templates with ease. It offers an intuitive interface, allowing administrators to define and incorporate the necessary fields and information required for each permit. Users can easily tailor permits to various permit types, ensuring consistency and compliance throughout the process.
2. Streamlined permit lifecycle When a new permit is requested, all parties responsible for the safe execution of the permit are notified and prompted to signoff on their relevant sections. Civillo users can easily view pending permits and their active status through the map view. Once approved permits become active and expire automatically based on their pre-defined expiry lengths. If necessary, users can easily and quickly renew expired permits. By automating large parts of the permits process organizations can streamline workflows, reduce administrative burdens, and ensure compliance.
3. Active permit document

Once a permit is approved by all responsible parties the permit document is viewable and signable by anyone, including non-Civillo users. This allows the active permit to be easily distributed to anyone who needs it in order to be compliant on a work site.

A flowchart of the permit lifecycle, detailed further in the “Lifecycle states” and “How to” subsections, is shown in Figure 3. It builds on two reference diagrams: Figure 1 shows what can happen to a permit at any stage, and Figure 2 shows the signoff loop that the lifecycle repeats. To read them:

• Rectangles are tasks carried out by a user, written as User: Task.
• Colored words are permit states. Larger words are final states.
• Hexagons are conditions Civillo checks automatically, such as a date passing.
• In Figure 3, groups with a blue border repeat, groups with a red border only apply when a condition is met, and groups with a purple border are optional.

flowchart LR
  accTitle: Permit events at any stage
  accDescr: A requestor can cancel a permit. Civillo moves it to renewal required when its valid date passes, to expired when its expiry date passes, and to lapsed after 60 days with no activity.

  cancel["`**Requestor:** Cancel permit`"] --> cancelled(["`**CANCELLED**`"])
  validDate{{Valid date passed}} --> renewalRequiredAny(["`**RENEWAL REQUIRED**`"])
  expiryDate{{Expiry date passed}} --> expired(["`**EXPIRED**`"])
  inactive{{No activity for 60 days}} --> lapsed(["`**LAPSED**`"])

  classDef state fill:transparent,stroke-width:0px
  classDef final font-size:1.4em
  class cancelled,renewalRequiredAny,expired,lapsed state
  class cancelled final
  class cancelled,renewalRequiredAny,expired,lapsed error

Figure 1: Events that can happen to a permit at any stage.

flowchart TD
  accTitle: Signoff loop
  accDescr: User 1 responds to the C/P. User 2 either signs off, which ends the loop, or requests changes, which puts the permit in changes requested until user 1 makes at least one change and updates it, after which user 1 responds again.

  loopStart((Start)) --> respond["`**User 1:** Respond to the C/P`"]
  respond --> signOff["`**User 2:** Sign off on the C/P`"]
  signOff --> loopEnd((End))
  respond --> requestChanges["`**User 2:** Request changes to the C/P`"]
  requestChanges --> changesRequested(["`**CHANGES REQUESTED**`"])
  changesRequested --> update["`**User 1:** Make at least one change to the C/P then update`"]
  update --> respond

  classDef state fill:transparent,stroke-width:0px
  class changesRequested state
  class changesRequested error

Figure 2: The signoff loop. C/P stands for category or permit.

flowchart TD
  accTitle: Permit lifecycle
  accDescr: From a requestor requesting a permit, through category and permit signoff loops, approval, activation, close off and completion, with optional renewal, progression and revocation.
  start(["`**START**`"]) --> request["`**Requestor:** Request the permit`"]
  request --> pcs(["`**PENDING CATEGORY SIGNOFF**`"])

  subgraph eachCategory [For each regular category attached to the permit]
    categoryLoop[["`**Signoff loop** with **Responder** as **User 1** and **Category signoff user** as **User 2**`"]]
  end

  pcs --> eachCategory
  eachCategory --> ps(["`**PENDING SIGNOFF**`"])

  subgraph eachSignoffUser [For each permit signoff user]
    permitLoop[["`**Signoff loop** with **Requestor** as **User 1** and **Permit signoff user** as **User 2**`"]]
  end

  ps --> eachSignoffUser
  eachSignoffUser --> approved(["`**APPROVED**`"])

  subgraph holders [If possible permit holders are specified]
    relinquish["`**Permit holder:** Relinquish hold on the permit`"] --> hold["`**Possible permit holder:** Hold the permit`"]
  end

  subgraph openCategories [Optional: if open categories are specified]
    applyOpen["`**Requestor:** Apply open categories to permit`"]
  end

  approved --> holders
  holders --> openCategories
  openCategories --> validFrom{{Once valid from date is passed}}
  validFrom --> active(["`**ACTIVE**`"])
  active --> close["`**Requestor or permit signoff user:** Close off permit`"]
  close --> pco(["`**PENDING CLOSE OFF**`"])

  subgraph closeOff [For each close-off category if any are specified]
    designate["`**Requestor:** Designate category signoff user`"] --> closeOffLoop[["`**Signoff loop** with **Requestor** as **User 1** and **Category signoff user** as **User 2**`"]]
  end

  pco --> closeOff
  closeOff --> completed(["`**COMPLETED**`"])

  subgraph renewal [Optional: renew permit]
    renew["`**Requestor:** Renew permit (given maximum renewals not yet exceeded)`"]
  end

  subgraph progression [Optional: if progression categories are specified]
    progress["`**Requestor:** Apply progression category to permit`"]
  end

  subgraph revocation [Optional: revoke permit]
    revoke["`**Permit signoff user:** Revoke permit`"]
  end

  %% a junction gathers the approved and active branches, like the shared line in the original deck
  actionsJunction@{ shape: f-circ }
  approved & active --> actionsJunction
  actionsJunction --> renewal & progression & revocation
  renewalRequired(["`**RENEWAL REQUIRED**`"]) --> renewal
  renewal & progression --> pcs
  revocation --> revoked(["`**REVOKED**`"])

  classDef state fill:transparent,stroke-width:0px
  classDef final font-size:1.4em
  class start,pcs,ps,approved,active,pco,completed,renewalRequired,revoked state
  class start,completed,revoked final
  class start,completed primary
  class pcs,ps,pco warning
  class approved,active success
  class renewalRequired,revoked error
  class eachCategory,eachSignoffUser repeated
  class holders,closeOff conditional
  class openCategories,renewal,progression,revocation optional

Figure 3: The permit lifecycle.