Administrator setup guide

1. Sign in and secure the administrator account

Open the organisation’s private BidDoctor address supplied by your implementation contact. Confirm the address uses HTTPS and your organisation’s subdomain.
Sign in with the administrator email and temporary password delivered to you separately. Do not send passwords in the same message as the address.
Open My account and change the temporary password. Use a unique password and do not share administrator accounts.
Set up two-step verification under My account. If your organisation requires it for everyone, the system administrator can enforce it in Admin → Settings & rules.

Never enter real records in a shared demo. The public demo is shared and automatically rebuilt every 24 hours. Your organisation’s private instance is isolated and is not part of that reset.

BidDoctor sign-in page with email and password fields — Sign in at your organisation’s private HTTPS address using the administrator details delivered to you separately.

Change password form in My account — Change the temporary password to a unique password of at least 10 characters.

Two-step verification setup in My account — Set up two-step verification with an authenticator app.

2. Confirm organisation rules

Review Admin → Settings & rules, including your clearance authority and threshold, approval limits, payment period, standstill, performance-security deadlines, and stage targets.
Confirm the organisation name and short name shown in the system. Ask your implementation contact to correct deployment-level defaults if needed.
Review Admin → Public holidays. Add the current gazetted dates for Eid al-Fitr and Eid al-Adha, plus any organisation-specific closures.
Confirm the Open Contracting Data Standard prefix before publishing OCDS data; use a prefix registered for your organisation.

Have Legal, Procurement, Finance and the Accounting Officer approve the rules before entering live contracts. The supplied values are starting points, not a substitute for your organisation’s approved procedures.

BidDoctor Settings and rules page showing entity, regulatory limits, alerts, security and pipeline settings — Settings & rules: review every threshold, target and organisation detail before using real contracts. The example values shown are not a recommendation.

Lower part of BidDoctor Settings and rules showing alert, security and drafting pipeline settings — Review alert windows, two-step verification, OCDS settings and stage targets with your organisation’s responsible officers.

3. Add users and assign roles

Open Admin → Users → Add user.
Use each person’s individual work email, department and least-privilege role. BidDoctor includes Administrator, Legal, Procurement, Company Secretary, Contract manager, Finance and Management roles.
Set a temporary password of at least 10 characters, then deliver it securely and ask the person to change it at first sign-in.
Deactivate accounts promptly when access is no longer required. Deactivation preserves the audit history.

See Roles and permissions in the user manual before granting administrator access.

BidDoctor Users administration screen with sample users and Add user form — Admin → Users: add individual accounts, assign each person the least-privilege role, and share initial passwords separately.

4. Configure email and electronic signing

Ask your implementation contact to configure your approved mail service. Then open Admin → Email and send a test message to an administrator.
Test a signing invitation using an approved test contract and recipient before inviting an external supplier. Signing invitations and one-time codes are sent to the recipient’s email address.
For trusted production PDF seals, your organisation should provide a signing certificate from an appropriate certification service provider. Without one, BidDoctor uses a self-signed development seal that PDF readers will not trust.
Confirm the sender address, public app URL and email links before using real procurement records.

Email configuration can send real messages. Do not use shared demo credentials or real supplier addresses for informal testing.

Example BidDoctor electronic-signing form with ordered signer fields — Electronic-signing example from the demonstration interface. Test the signing flow only with approved internal recipients before inviting a supplier.

5. Protect records and prepare for go-live

Configure Admin → Backups with an encrypted off-server destination. Keep the encryption passphrase outside BidDoctor and test a restore before go-live.
Confirm that your ICT team has access to the organisation’s recovery contact, hosting account and domain renewal arrangements.
Agree who may create, review, approve, sign and close contracts. Test one representative contract from intake to closure with the relevant roles.
Check expiry alerts, email delivery, calendar subscriptions, user access and audit records with fictional test data.
Before importing records, confirm the approved retention schedule and the secure source/export process with your records manager.

BidDoctor Backups page showing encryption and backup schedule settings — Set a unique backup passphrase and agree the schedule and retention with your ICT team. This example screen has not yet been configured.

BidDoctor Backups page showing off-server destination options — Choose at least one approved off-server destination, save and test it, then create a backup and verify a restore.

6. Know which environment you are using

Each client deployment has its own Railway project, application, persistent volume, database, users and uploaded documents. Client subdomains do not share data. The shared demo at demo.biddoctor.app contains fictional data and is automatically reset; never enter your organisation's records there. The separate biddoctor.app service is not the shared demo.

Your private instance is configured not to run demo resets. Do not change DEMO_MODE, DEMO_SEED, the database path or the persistent-volume settings. Contact your implementation or ICT administrator for hosting changes, restores, domain changes or access recovery.

For detailed task instructions, use the BidDoctor user manual and the administrator section of the documentation.