Account Executive who reports to Kazuki Hashimoto in the Japan region — from a raw directory export all the way through to a finished regional ruleset with rules for the whole team and its leadership.
What you’ll learn
- Extract and export the Sales division and read its reporting line in a spreadsheet.
- Build a team by hand from a dimension, an attribute, and policy rules for the reports and the manager.
- Aggregate a team into a wider geography by pointing one attribute’s rule at another attribute.
- Add leadership to a team as named users and as attribute combinations, then follow the audit trail.
- Extend an imported region ruleset instead of rebuilding it, and edit a justification on an active rule.
Prerequisites
- A workspace with a completed Okta or Google Workspace integration sync.
- The
prvCLI authenticated to your workspace.
The IDs shown below (
drusr_…, dratr_…, drdim_…, poset_…, and so on) are examples. Your records will have their own IDs. Where a command needs an ID you provide, it is written as an UPPERCASE_TOKEN that you replace with the real value from the previous step’s output.1. Extract the sales user list
1
List the directory users
Start with the list of every directory user that was imported.
2
Filter to the Sales division
You only care about sales for this step, so filter the list down straight away. In the Next Step menu select Filter List of Results, leave Filter by an exact value in specific field selected, choose the
org.division field, and select Sales.3
Review the filtered count
The count of filtered records is shown below the table. Your directory has 359 users in the Sales division. The table shows each user’s name, email, country code, department, division, title, and the full name of their manager, which is the column that tells you how the teams are put together.
2. Export the filtered list
1
Open the export option
There are several ways to work out how many sales teams you have. This step works through it the long way first, because that is where most people start, and a spreadsheet is the easiest place to read the reporting line.In the Next Step menu select Export Results to File or Spreadsheet. The filter you applied is carried into the export command.
2
Choose the person columns
You are asked which attributes to include. Press SPACE to check or uncheck a column and use the arrow keys to scroll through the whole list. Uncheck the state, the employee ID, the timestamps, and the cost center, because you do not need them for this work. Uncheck the division as well, since every row in this export is already in the Sales division. Keep the manager ID for cross-referencing later, and keep the direct report count.
3
Choose the manager columns
Scroll further down to the manager fields. The manager’s information is what turns a flat list of people into a reporting line, so keep the manager’s own manager ID, their title, their department, and their country code.Press ENTER/RETURN to save your selection and choose CSV as the format, which imports into Google Sheets without any conversion. The file is written to the
~/Downloads/provisionr folder and each export is timestamped.3. Import the CSV into Google Sheets
1
Import the file
Open the Google Sheet that you want to work in and select File, then Import, then the Upload tab, and choose the CSV file from your downloads folder.Be sure to choose Insert new sheet rather than Create new spreadsheet, so the data lands beside anything else you are keeping in the same file. Leave the separator type on Detect automatically and select Import data.
2
Note the sheet name
The imported sheet is named after the export file, so it carries the timestamp of the export and you can tell one extract from another later.
4. Hide columns you do not need
1
Hide the columns you are not reading
There is nothing special about this file. It is an ordinary CSV, and it carries more data than you need for the question you are answering right now. Select the columns you are not reading and hide them so the sheet is easier to look at. The IDs and the email addresses are good candidates, and you can unhide them at any point.
2
Keep the columns worth reading
The columns worth keeping in view are the following.
is_manager, which is a1or a0for each user.full_name,org.country-code,org.dept, andorg.titlefor the person.count.direct_report_users, which tells you how large each manager’s team is.- The
included.user_managercolumns for the manager’s name, country code, department, and title.
5. Filter to the managers
1
Filter on the manager flag
You have a lot of people in the sheet and only some of them define a team. Turn on the filter from the toolbar, open the filter menu on the
is_manager column, and filter it to the value 1.2
Read the manager count
The status bar at the bottom right of the sheet tells you how many rows are displayed out of the total. Your directory has 38 managers with direct reports in Sales, which is a much easier number to work with than 359.Sort the remaining rows by the
org.title column so that the directors, the regional sales managers, and the vice presidents group together.6. Read the manager rows
1
Read the sorted list
Read down the sorted list. You will see regional sales managers for individual countries and sub-regions, directors above them, and a set of vice presidents whose own managers hold the title of Regional President and sit in the Office of the President department.
2
Count the geographies
Select the manager country code cells for those vice president rows and the count appears at the bottom right of the sheet. That count is the number of geographies your sales organization is currently divided into, and it is the first real answer to how many teams exist.
3
Decide to build a pivot table
You could carry on from here by filtering on the country code column, one country at a time. A pivot table shows you the same thing all at once, so build one of those instead. This is spreadsheet work rather than Provisionr work, and it is worth the two minutes it takes.
7. Create a pivot table
1
Insert the pivot table
Select Insert, then Pivot table, and create it in a new sheet. The pivot table editor opens on the right hand side with sections for rows, columns, values, and filters.
2
Add the row fields
Add row fields only, in the order that you want to read them. Add the department first, then the job title, then the individual’s full name, and then drag the country code to the top of the list so that the whole table is grouped by geography.
org.country-codeorg.deptorg.titlefull_name
3
Leave columns and values empty
Leave the columns and the values sections empty. You are using the pivot table to lay the reporting line out, not to total anything up.
8. Adjust the pivot table layout
1
Turn off the totals
A pivot table adds a total row for every field by default, and those rows get in the way when you are reading names. In the editor, uncheck Show totals on each of the row fields.
2
Repeat the row labels
Check Repeat row labels on the department and the job title fields. Every row now carries its own department and title instead of leaving them blank under the first entry, which makes the table far easier to read and to copy values out of.
3
Add the manager's country code
Add the manager’s country code as a row field above the rest, so each block shows the country the team’s manager sits in next to the country the team members sit in.
9. Read the pivot table
1
Compare the two country columns
Scroll through the table and compare the two country columns. For most blocks the manager’s country code and the members’ country codes are the same, which tells you that those teams are organized by country.
2
Spot the teams that cross borders
Some blocks do not line up. A block of French users whose manager sits in the Netherlands is a European region whose manager happens to be somewhere else in Europe. Teams cross borders, so the country code on a user is a useful signal rather than a definition of the team.
3
Choose how to build the teams
That leaves you two ways to build these teams. You can build them by the country or region a person is in, or you can build them by who a person reports to. Some organizations carry the country or the region in the job title or in another profile field, and where that data exists it helps a great deal.
10. Filter to a specific region
1
Follow one region through the pivot
Pick one region from the pivot table and follow it through. Reading down a single block you will see the vice president of sales for that region, the director of sales, the regional sales manager, and then all of the individual contributor titles below them.
2
Check the leadership chain in reverse
You can check that reading in reverse. Take one individual contributor, look at the manager named on their row, and then find that manager elsewhere in the table as a director or a vice president. That is the leadership chain for the region.
3
View the region as a flat list
Go back to the data sheet to see the same region as a flat list. Remove the
is_manager filter you applied earlier by opening its filter menu and selecting all values again, then filter the org.country-code column to the region you are working on and sort by org.title.The status bar now tells you exactly how many people are in that region, and the direct report counts show you which of them is the manager. That is the Japan sales team.11. Understand your data
1
Understand the team structure first
Before you touch Provisionr, you need to understand the data you are looking at and what the team structure is.
2
Get the data you are missing
If you do not have that data, there are several ways to get it. Some of it you already have access to and can extract yourself, as you did above. The rest usually comes from asking someone to paint you a picture, whether that is a whiteboard session or the slide from a recent all-hands meeting that shows the managers and which teams report where. That is normally enough to make sense of it.There is no easy button for this part until you have the data to work with.
12. Create the regional team dimension
1
List the existing dimensions
Back in the terminal, list the dimensions you already have so you know what you are adding to.
2
Choose to create a dimension
Your directory already has a Sales Region dimension that arrived with your Identity Provider data. Leave it alone for now. This step builds a different flavor of the same idea so that you can compare the two afterwards.If you select Create Attribute for Dimension you are asked which dimension the attribute belongs to, and the one you want does not exist yet. Press CTRL+U to go back and select Create Dimension instead.
3
Name the dimension
Give the dimension a name such as
Sales Manager Team and accept the generated handle and the remaining defaults. The dimension is created and activated immediately, with attributes and conditions enabled and an expiry of 30 days inherited by anything you create inside it.13. Add an attribute for the regional team
1
Create the attribute inside the dimension
Select Add Attribute to Dimension from the Next Step menu to create the team itself inside the dimension you just made.
2
Name the team
The name is your choice. You can name the team after the country, after the region, or after the manager who runs it. If you do not yet know what the teams are called, using the manager’s name is a very common approach, and you can rename both the name and the handle later once the policies are working. This example names the team after the manager and the region.
3
Inherit the expiry default
You are then asked whether to override the expiry that the attribute inherits from the dimension. Deprecation gives users and services a grace period before access is removed, which is useful for job role changes where people need a few days or weeks of overlapping access. Leave the answer on No to inherit the dimension’s setting, and activate the attribute.
14. Create a policy rule for the regional team
1
Start the create wizard
The attribute exists but nobody is on it yet. Go to the rules for the attribute, and since there are none, go straight to creating a new rule.
2
Write the justification
Answer Yes to the justification prompt and describe what the rule is for. A rule has no description by default unless it was imported during an integration sync, and for a custom rule like this one a short sentence gives you an at-a-glance justification during user access reviews. If you skip it, the rule is created with a placeholder description that names you as its creator.
3
Choose the manager condition type
The rule is created in a staged state. No users are granted access while a rule is staged, and you can add or remove conditions for as long as it stays that way. Once a rule is active its conditions are read-only, and you would duplicate it to make a new revision.Choose the condition type next. This team is defined by who its members report to, so select Users reporting to a Manager and search for the manager by name.
15. Review the staged users
1
Review the staged condition and users
Save the changes and the CLI prints the conditions on the rule and the users the rule currently stages. Kazuki Hashimoto has 16 direct reports, so that is the number of staged users you see.
2
Note that the manager is excluded
This does not include the manager themselves. A manager reports to their own manager, not to themselves, so they are not matched by this condition.
3
Decline further conditions and activate
You are asked whether to add another condition. You could add one here if you wanted to split this team further, for example to create separate account executive, sales development, and customer success teams under the same manager for cases where those roles should not share access. For a regional team you do not need that constraint, so answer No and activate the rule.
16. Add the manager as a named user
1
Create a second rule
The team still needs its manager. Select Create another Policy Rule and create a second rule on the same ruleset.
2
Write the justification
Select the role for the rule, which is the
directory_attribute - member role, and give the rule a description of your own.3
Add the manager as a named user
This rule is for one individual, so select Named User as the condition type and search for the manager. Save the changes and activate the rule.
17. Review the rules on the ruleset
1
List the rules
List the rules on the ruleset to see both of them together.
2
Navigate to the ruleset's users
The
manifest_users column adds up to the whole team, which is the direct reports plus the manager. To see the people rather than the rules, select Describe/Manage Parent Relationship, choose Policy Ruleset, and then view the users on that ruleset. Every user carries the ID of the rule that qualified them, so the rule ID is the same for everyone except the manager.18. View the created attribute
1
Filter the attribute list to the dimension
Look at the finished team from the outside. Select Manage a Different Resource, go to the directory namespace, choose the attribute resource, and list the attributes.The unfiltered list holds every attribute in your directory, so filter it. Select Filter List of Results, then Filter by associated relationship, then Directory Dimension, and search for the dimension you created. Only dimensions that already have attributes appear in this picker.
2
Review the finished team
The team is set up and the count of users on it is the manager and their reports. That is the whole of creating a team by hand. You create the dimension if you do not have one already, create the attribute, add the rule for all users who report to that manager, and add the rule for the manager themselves. Once those are activated you can attach the attribute anywhere else you need it.
19. Create a dimension for a wider group
1
Leave the create wizard and list dimensions
A single regional team is rarely the only grouping you need. The next attribute covers a wider geography that contains Japan along with the other teams around it.Before you create it, decide which dimension it belongs in. The manager team dimension is not the right place, because this attribute is not one manager’s team. Press CTRL+C to leave the create wizard and list your dimensions again.
2
Create the Sales Geo dimension and attribute
Sales geographies get called many different things across organizations, which is part of why this work is hard to keep consistent. This example creates a new dimension named
Sales Geo, accepts the defaults, and then adds an attribute inside it for the wider region.20. Use the team attribute as a condition
1
Create the rule and choose the condition type
Create a rule on the new attribute with a justification such as
Japan team is part of APJ. and then choose the condition type.You could rebuild this membership with a string match or with the manager, but you already have an attribute that resolves those people through its own ruleset. Point at that attribute instead so there is a single source of truth. Select Users attached to an Attribute.2
Search for the team attribute
You are then asked how you want to find the attribute. You can pick one off an existing user, or you can search all attributes. Select No - Search for Attribute, choose the manager team dimension, and select the team you created.
3
Select the attribute and activate
The attribute picker shows the ID, the vendor, the dimension handle, the name, the handle, and the number of users on each attribute. Take note of the footer, which tells you that these options have not been filtered based on the conditional users.Save the changes and the wider attribute is populated with the users the team attribute already resolves. Add no further conditions and activate the rule.
21. Compare the attribute with your data
1
Compare the row counts
Go back to the spreadsheet with the region filter still applied and compare the row count there with the number of users on the attribute. The attribute holds the manager and their direct reports. The sheet holds those people plus the director of sales and the vice president of sales, who report elsewhere in the leadership chain and are therefore not matched by a rule that qualifies the manager’s reports.
2
Decide how to add the two leaders
There are three ways to bring the two leaders in. You can add them by job title, which is not distinct because those titles exist in every region. You can add each of them as a named user. You can add them by their job title and their country code together, so the pair of conditions identifies one person without naming them.The steps below do both of the last two, one leader each way, so you can see how each behaves and decide which suits your organization.
22. Return to the team attribute’s rules
1
Navigate to the team attribute's rules
The leaders belong on the Japan team itself, which is the upstream attribute, rather than on the wider region attribute that aggregates it. Anything you add upstream flows through to the aggregate.Select Manage a Different Resource, go to the directory namespace, choose the attribute resource, describe the team attribute, and then select View/Manage Policy Rules.
2
Create a third rule
Both of the rules you created are listed. Select Create Policy Rule to add a third.
23. Add the director as a named user
1
Write the justification
Keep the spreadsheet open beside the terminal so you can copy the name you need. Select the member role for the rule, the same one the other rules use, and write the justification.
2
Add the director as a named user
Work down the condition types. This is not an attribute attachment and it is not a manager relationship, and a string match would not give you unique data to match on for one individual. Select Named User, paste the director’s name into the search, select them, and activate the rule.
24. Review the three rules
1
List the rules again
Go back up to the ruleset and list the rules again to confirm the addition.
2
Review the new rule
The new rule carries one condition and one user, and that user is the director of sales for the region.
25. Add an unnamed user by attribute combination
1
Create the rule and use an existing user
The vice president goes on the same team, added a different way. This rule combines a job title with a country code, so you do not need to know who the person is, only where they sit in the org chart.Create another policy rule with a justification such as
VP of Sales for the region. and select Users attached to an Attribute as the condition type.This time answer the attribute question with Yes - Use Existing User. You already know a person who holds the attributes you want, so search for them by name and then choose which of their attributes to use rather than searching the full attribute list.2
Review the over-broad staged users
Choose their title attribute and save the changes. The staged user list comes back with every vice president of sales in the company, which is not who you want.
26. Narrow the rule with a second condition
1
Add the country code condition
Both conditions have to be in place for this to work, so answer Yes when you are asked to add another condition. Select Users attached to an Attribute again, and this time select No - Search for Attribute so you can see the attributes themselves.Scroll or search down to the country code dimension and select the country you want. The region dimension is a separate one and is not related to the country code.
2
Review the single matching user
The changes are shown back to you before they are saved, and the staged user list comes back with the single user who matches both conditions.
3
Activate the rule
You could add a further condition such as the department if you needed to narrow it more, and in this case you do not. Answer No and activate the rule. The ruleset now carries four rules, and the attribute holds the whole regional team including its leadership.
27. Attributes, sync, and downstream policies
1
List the wider region attribute's rules
Go back to the wider region attribute you built earlier and look at what changed there. Select Manage a Different Resource, go to the directory namespace, choose the attribute resource, list the attributes, and describe the wider region attribute. Then select View/Manage Policy Rules.
2
Note the stale manifest count
That attribute still has its single rule, and its
manifest_users count is the count from before you added the two leaders upstream. It has not picked up the change yet.When you modify a ruleset, the rules on that ruleset sync in real time. Anything else that uses that ruleset is picked up by the background job that runs afterwards, which is called a rule qualification sync.The rule qualification sync runs hourly, daily, or weekly depending on your subscription. Changes you make to a ruleset are applied to that ruleset immediately, and policies that reference it downstream are updated on the next sync.
28. Review your existing dimensions
1
List the dimensions
Now go back and look at the Sales Region dimension that existed before you started, to see what is in it and whether you can use it. Select Manage a Different Resource, go to the directory namespace, choose the dimension resource, and list the dimensions.
2
Describe the Sales Region dimension
The two dimensions you created during this step are in the list alongside the rest. Their
profile_key and integration.vendor columns are empty, because the data behind them did not come from your Identity Provider. You created them.Select Describe/Manage Dimension for the Sales Region dimension and have a look around it.29. Review the existing Sales Region attributes
1
List the related attributes
Select View/Manage Related Attributes to see the attributes inside the dimension. There are 11 of them.
2
Spot check the Japan attribute
These look close to the teams you found in the spreadsheet. Spot check them with the user counts. The Japan attribute holds 16 users, and you already know from the sheet that the region has more people than that, so something is missing. Describe that attribute and look at who is on it.
30. List the policy users on the region
1
View the region's users
From the attribute, view its users.
2
Read the title and rule columns
Read down the
user.org.title column and a trend appears. The manager is not there, the director is not there, and the vice president is not there. These are all individual contributors.Read the rule.id column as well. There are only a few distinct rule IDs across the whole list, which tells you the attribute is fed by a handful of rules rather than by one rule per person.Nothing is being configured here. This is following the breadcrumb trail through the data to work out how these users got where they are.31. Follow the breadcrumb to a directory user
1
Describe the first user
Select Describe/Manage Policy User and pick the first user in the list, then view the directory user behind that record.
2
View the user's attributes
Select View Attributes, Groups, or Resources to see everything Ayaka Ishikawa is attached to. The
resource.parent column names the dimension of each record, so you can see at a glance that they carry a region, a cost center, a division, a department, a title, and a country code, along with the sales region you are investigating.3
Follow the sales region row
They are mapped to the sales region. The next question is how they got there, and the
rule.id on that row is what answers it.32. Check the identity profile
1
Describe the identity
Before following the rule, check whether the value came from your Identity Provider at all. Go back to the directory user, select View Identities, and describe the identity.
2
Confirm the value was not imported
Scroll through the profile keys on the identity. You will find the country code, the department, the division, the region, the title, and a
profile.reportsTo value that names the sales manager for the region. There is no sales region key on the profile.The sales region on this user was not imported. It was granted by a Provisionr rule, which is what you are about to find.33. Find the rule that granted access
1
Describe the policy user record
Typing long IDs by hand gets tedious, so copy the ID of the policy user record for the sales region and paste it into the policy user describe command. The list filters straight down to that one record.The describe output shows the three records that surround it.
2
Open the rule
The rule that qualified this user is described by its job title, which tells you there is a rule per title on this ruleset. Select View Policy Rule to look at it.
34. Review the rule conditions
1
View the conditions
The rule carries two conditions, and both have to match for a user to qualify.
2
Read the two conditions
The first is a manager condition on the same manager you have been working with all the way through this step. The second is an identity condition where the title equals a fixed value, which is a string match on the profile data.That combination is not a problem in itself, and it explains the shape of what you saw in the user list. Every individual contributor title has its own rule, and there is no rule for anyone in leadership.
35. View the audit log for a legacy rule
1
List the rule's audit logs
Someone created these rules. Select View Audit Logs for this Policy Rule and then View Logs for this Record to see the history of this rule alone.
2
Read the two events
Two events are recorded, one for the creation of the rule and one for its activation, and both name the person who performed them. On a directory with real history these would be dated months back, which is usually long enough for everyone involved to have forgotten the ticket that prompted them.
36. Describe an audit log record
1
Describe the creation event
Describe the creation event to see the whole record.
2
Read what the log records
The log tells you who created the rule, what they created, which record it belonged to, and how it was performed. It does not tell you why, because a reason was never recorded on the rule itself. That is what the justification description on a rule is for.From here you can select View/Manage Logs for Same Actor to see everything else that person did, or View/Manage Logs for Same Event Type to see every rule creation across the workspace.
37. Add a rule to the legacy ruleset
1
List the ruleset's rules
You know where the ruleset came from, and it is missing the manager, the director, and the vice president. Rather than replacing it, add those rules to it.Every command is printed at the top of the output, so you can copy the rule list command from earlier and paste it back into your terminal instead of walking the menus again.
2
Create a rule without a justification
Select Create Policy Rule. This time answer No to the justification prompt so you can see what happens without one.
3
Search for the manager by a single keyword
Select Users attached to an Attribute, then Yes - Use Existing User, and search for the sales manager for the region.The search takes a single keyword, so a two-word search returns no results. Search for one word instead and select the manager from the list.You are then asked which of that user’s attributes to use. Choose their title. The rule is not tied to the individual, it is tied to anyone holding the title of sales manager for that region, which works as long as your HR data keeps job titles consistent. Save the changes, add no further conditions, and activate the rule.
38. Activate the rule
1
Run the activate command
Activation asks you to confirm, and it prints the current state of the rule along with what activation means.
2
Confirm the placeholder description
Take note of the
description value in the table above the prompt. Because you skipped the justification, the rule was created with the placeholder description that names you as its creator. Answer Yes to activate.39. Edit a justification message
1
Open the update wizard
List the rules again and the new one sits alongside the imported ones with its placeholder description. The existing rules use a readable syntax of the region, then the job title, so copy that syntax and apply it to the new rule.Describe the rule you want to change and select Update this Policy Rule.
2
Rewrite the description
You are asked which key you want to change, and you enter
description. The current value is shown in the multi-line field for you to edit, so clear the placeholder and type the description you want. Press CTRL+D to submit the field and save the change.The rule is already active, and the description can still be edited. It is the conditions on an active rule that are read-only.
40. Confirm the change in the audit log
1
Describe the newest audit entry
Select View Audit Logs for this Policy Rule and describe the newest entry. The change you just made was logged field by field.
2
Read the before-and-after values
The old value and the new value are both recorded, along with which key changed and who changed it, so you have the full audit trail for an edit as well as for a creation.
41. Add a rule for the sales director
1
Confirm the renamed rule
Go back to the rule list for the ruleset and confirm the renamed rule is there with one condition and one user.
2
Write the justification
Select Create Policy Rule to add the director of sales, this time answering Yes to the justification prompt and following the same syntax as the rules already on the ruleset.
3
Build the rule from title and country code
This rule is built from criteria rather than from a named user. When a person leaves or a manager changes, a rule built from a job title and a country code takes care of itself, because the new director carries the same attributes as the last one. Sales organizations restructure often, and attributes that map to what is already in the system mean the access follows the change.Select Users attached to an Attribute, then Yes - Use Existing User, and search for the director. Choose their country code attribute first, which stages everybody in that country. Add a second condition the same way, using the same individual, and choose their title this time. The staged list comes down to one record.Activate the rule.
42. Add a named user in leadership
1
Create the rule for the vice president
Go back to the ruleset and list the rules. The sales manager and the sales director are both on it now, and the vice president is still missing.This one goes on as a named user. In a smaller sales region the vice president may be based in another country entirely, so a condition built on the country code would leave them out. A named user lets you say that this individual is inside the boundary even though their attributes place them outside it.Create the rule with a justification in the same syntax, select Named User, and search for the person by name, email address, or any other data you have about them.
2
Read the named-user condition
The condition type is recorded as
user and it is keyed on the individual, so that person is on the policy as an exception. When a new vice president arrives you have the option to change it.43. Add coverage from cross-functional managers
1
Review the vice presidents across regions
Leadership covers for each other while people are at conferences or on vacation, so a region’s policy may need people who are not in the region at all, whether they are global, regional, or simply counterparts.Go back to the spreadsheet and clear the filters you applied so you can see all of the vice presidents of sales across the regions. Whether these people belong on the policy may be your call or someone else’s, and the data gives you what you need to decide.
2
Add another named-user rule
Add one more policy rule to the ruleset with a justification that records why the person is there, add them as a named user in the same way as the previous rule, and activate the rule.
44. Review the final policy users
1
List the region's users
Go back out to the ruleset, then to the resource, which is the Japan attribute itself, and list all of its users.
2
Review the finished team
The attribute started this step with only its individual contributors. It now carries the sales manager, the director of sales, and both vice presidents alongside them, and each one is on the list through a rule you can point at.That is how you take an existing policy that was built most of the way there and finish it, rather than starting again.