Members and user applications
A member is somebody who belongs to your organisation. The membership record is what carries their organisation-level permission template, what their work is attributed to, and what every register row they ever create points at. See Organisations and projects.
Two pages cover it. Organisation, then Directory is the list of your people. Organisation, then User Applications is the queue of people waiting to become one, and it carries a count badge in the sidebar while anything is pending.
Both are your own organisation's only. There is no route to another company's membership list, even for a host on its own project.
Three ways somebody joins
Worth knowing all three, because two of them produce something to approve and one does not.
An administrator adds them. Somebody in your organisation with permission to add people enters their email address and they are a member immediately. Nothing is queued and nothing is approved. This is the ordinary route for your own staff.
They apply. Somebody with a Teralo account searches for your organisation and requests to join. That lands in User Applications as a User Request.
A project administrator adds them to a project. When a host adds somebody to a project and names your organisation as the company they work for, that person gets project access straight away and their organisation membership arrives in your queue as a Project Admin application. They are on the job either way; what you are approving is whether they are one of yours.
Add somebody to your organisation
Two controls at the top of the organisation Directory, and which one you want depends on whether they already have a Teralo account.
Global Directory searches every account in Teralo. Find the person, pick the organisation permission template they should have, and they are in.
Create Account takes an email address. Teralo checks it as you type and tells you what it found before you fill anything else in: this person already exists and can be added, this person is already in the organisation, or this is somebody new. For somebody who already exists, their name and job title are filled in for you and left read-only, because they are that person's to change and not yours. For somebody new, enter their name and job title, and Teralo creates the account and emails them a welcome message with a temporary password to change.
Either way there is nothing for them to accept. The membership exists the moment you save it.
Adding somebody back who was removed reactivates their original record rather than creating a second one, so everything they did before still points at them, and their permission template is set to whatever you pick on the way back in.
Apply to join an organisation
From your side, this is the Join Organisation dialog, reached from the organisation switcher or from the last step of onboarding. It has two tabs.
Search and Join searches by organisation name, and optionally narrows by business number or country. Search results show each organisation's name, description, business number and office address, which between them are how you tell two similarly named companies apart. Pick yours, add a short message saying who you are, and send it.
My Applications lists what you have sent and where each one got to, including the reviewer's response if they left one. A pending application can be withdrawn from here.
You can apply to more than one organisation, and applying does not commit you to anything. Nothing changes for you until somebody approves it.
Read the queue
The User Applications page is one table: who applied, whether it came from them or from a project administrator, the status, when it arrived, and the message or the context.
For an application raised by a project administrator, the Details column names the person who added them and the project they were added to. That is usually the whole answer to "who is this": somebody put them on a job, and the host expects them to be working for you.
Approve an application
Approve opens a dialog with two things in it, and only one of them matters much.
The Response Message is optional and goes back to the applicant, so it is a good place for a welcome note or an instruction about what to do first.
The Permission Template is the decision. It sets what this person can do at organisation level from the moment they are approved.
Choosing the permission template
Pick one. Approving with No template is allowed and Teralo warns you in red when you do, because the result is a member who is in the organisation and can do almost nothing in it, which reads as a broken account rather than as a deliberate choice.
If your organisation has no templates at all, the dialog says so and offers a link to the permissions page. Write the templates first; approving a queue of people onto nothing is a queue of support requests a week later. See Permission templates.
The template you choose here is the organisation one. It has nothing to do with what they can see on any particular project, which comes from a project template assigned when they are added to that project. See Inviting people to a project.
Reject an application
Reject takes an optional reason, which is sent to the applicant. Give one. A refusal with no explanation reads as a mistake and comes back as an email to somebody.
What rejection does depends on where the application came from.
A user request is simply declined. Nothing changes for them; they were never in your organisation.
An application can only be reviewed once. A second attempt on one somebody has already decided is refused.
What unaffiliated means
A project administrator's application is different, and the dialog says so. The person keeps the project access the host already gave them, and their standing with your organisation is marked unaffiliated. They are on the job, doing work, and not one of your members.
That is the correct outcome when a host has guessed the wrong employer, and it is worth telling the host so they can correct it. It is also worth knowing when you are on the other side of it: being unaffiliated with the organisation you were filed under does not take your project access away.
Remove somebody from the organisation
From the organisation Directory, select the person and delete. It takes effect immediately and Teralo emails them to say so.
Removal is a revocation, not an erasure. Their membership record stays exactly where it is, because every register row they ever created points at it: their mail, their observations, their inspections, their uploads, their claims. Deleting the record would take all of that with it. What removal does is set the membership to removed and clear the things that would keep them working.
What gets cleared is the scaffolding of membership rather than the record of the work:
- their project administrator status on every project
- their place in every mail distribution group
- their place on the distribution lists of individual incidents, injuries, meetings, observations and submittals
- their obligation to submit a site diary
Removing somebody from the organisation therefore removes them from every project it hosts. That is nearly always what you want when a person leaves. Do it the same day, and see the note on reviewing templates in Permission templates.
One thing removal deliberately leaves alone
An in-flight approval step assigned to them is not cleared. That is a decision rather than an oversight: deleting the assignment would silently un-assign a live approval, and a workflow can end up with no approver at all and no signal that it happened. Leaving it means the run parks visibly and somebody has to deal with it.
They stop being emailed about it, because the notification fan-out skips a removed member. So the practical effect is that an approval waiting on somebody who has left shows up as a stalled workflow rather than as nothing. Reassign it. See Assigning approvers.
Who can do what
Four permissions, across two pages.
Viewing user applications opens the queue. Managing user applications enables Approve and Reject. Splitting them lets somebody see who is waiting without being the person who decides.
Adding people and removing people are separate from each other and from both of the above, so somebody can bring a new starter in without also being able to take anybody out.
Organisation administrators hold all four automatically.
One thing that surprises people: Teralo's own staff do not approve or reject your applications. Superuser access deliberately stops short of it, because who belongs to your company is your decision and not platform maintenance.