# General Source: https://docs.settlemint.com/docs/console/organisation-settings/general Change the organisation's name, logo, modules, languages, time zone, terms, sign-out, signing holds, segregation of duties and approvals. General holds the settings that apply to the whole active organisation and have no page of their own, in six sections: - **Profile** holds the name, logo and modules. - **Language and time zone** holds the languages people can pick and the display time zone. - **Terms and disclosures** holds the documents that participants, the people and entities your organisation onboards, accept, and the redemption funding switch. - **Security** holds idle sign-out and the cooling-off period. - **Segregation of duties** holds the role pairs one wallet may not hold together. - **Approvals** holds the second-person approval rules. A section index beside the cards jumps to each section, and every section has its own address, such as `/org-settings/general#security`, that you can share. Name and logo changes carry no on-chain effect and change nothing about who can act for the organisation or which networks it can use. Both show wherever the Console shows the organisation, including the account menu at the top right. DALP writes the current name into every invitation email it sends on the organisation's behalf, and into the wallet names it sets at the custody provider when it creates a managed wallet or reapplies its role. ![General organisation settings page with the section index beside the Profile section](https://docs.settlemint.com/docs/screenshots/console-organisation-general.light.en.webp) [Screenshot] A section index in a card lists "Profile", "Language and time zone", "Terms and disclosures", "Security", "Segregation of duties" and "Approvals". The "Profile" card holds three rows. "Name" shows the organisation name with an "Edit" button. "Logo" shows a 48-pixel tile with "Upload" or "Replace" and, once a logo is set, "Remove". "Modules" lists the modules the deployment offers. The logo saves immediately, and the name waits for "Save". The other sections follow as their own cards. ## Before you start [#before-you-start] - **Who can change what.** You need the Owner role on the active organisation to change the profile and the settings here. Member does not carry that permission. In the Console, the "Segregation of duties" section follows the same rule as the profile. The "Approvals" section is the exception: an owner or a platform administrator, the role that administers the whole DALP deployment, can change it. A platform administrator who is a member of the organisation, in any organisation role, can turn an approval family off or lower its count. From a session in which they impersonate a member, they can turn a family on or raise a count, but not loosen either. Through the API, a platform administrator can also change the settings rows. - **Approvals start off.** Every approval family starts off, so a new organisation asks nobody for a second approval until an owner turns a family on in [Approvals](#approvals). The "Recovery" group under Administration is the one exception: it starts on, so an identity recovery waits for another owner or administrator until an owner turns that group off. - **Read-only view.** Any other member who opens a General link sees the Not available page. A platform administrator who is not an owner of the organisation sees the name, the logo and the settings as values, with no "Edit", "Upload", "Remove" or switch controls and one line under the title, "Organisation owners manage these settings." There is no not-authorised alert. The server still enforces the permission on every save. Approvals is the exception: a platform administrator can change its rules, as [Approvals](#approvals) describes. - **Limits.** The name accepts up to 32 characters, trimmed of leading and trailing spaces, and cannot be left blank. The logo is optional and accepts SVG, PNG, JPEG, or WebP up to 500 KB. The file is stored on the organisation record itself, and there is no image-dimension requirement. ## Steps [#steps] ### Open General [#open-general] Open "Organisation settings", then **General**. The name and logo you edit here belong to the active organisation, not your personal account. ### Change the name [#change-the-name] On the "Name" row of "Profile", select "Edit", type the new name, and select **Save**. "Cancel" or `Esc` leaves the name as it was. A counter such as "12/32" shows how many of the 32 characters you have used. The Console does not cut a longer name: it shows "Please use 32 characters at most." and does not save it. A name that another active organisation already uses is refused under the field with "Another organisation already uses this name. Choose a different name." The Console confirms a save with an "Updated successfully" toast. ### Set or remove the logo [#set-or-remove-the-logo] To set a logo, select **Upload** on the "Logo" row, or "Replace" when one is already set. "SVG, PNG, JPEG or WebP, up to 500 KB." is printed beside it. A read-only view shows "No logo" when none is set. Selecting a logo file saves it as soon as you choose it, and a "Logo uploaded" toast confirms it. To remove an existing logo, select **Remove**. It takes effect right away and a "Logo removed" toast offers "Undo" for a few seconds, which puts the logo back and shows "Logo restored". Supply a square image: the Console renders the logo into a fixed square everywhere it appears, a 48-pixel tile here and a small avatar in the account menu's **Organisation** submenu. Anything that is not already square gets cropped, and SVG survives that shrink better than a raster file does. Note (Only a logo removal has an undo): Each save overwrites the previous name or logo. Removing a logo takes effect at once, and its toast offers **Undo** for a few seconds. After that, or for any other save, the Console keeps no earlier version to revert to: if you need the previous name or logo again, you must re-enter or re-upload it yourself. ## Switch a module on or off [#switch-a-module-on-or-off] The **Modules** row lists the modules your deployment offers this organisation, with a switch for each. It reads "Choose which of the modules your deployment offers this organisation uses. A module that is switched off stays viewable but cannot be changed." When the deployment offers none, the row reads "Your deployment offers no modules." Turning a module off opens "Switch off ``?" and says "`` becomes read-only for your organisation. Nobody can change its records until an admin switches it on again." The dialog first checks what is still open and lists it, or reads "Nothing is open in ``." when nothing is. It checks these kinds: - "Open token sales" - "Open dealing requests" - "Running trading sessions" - "Open multisig wallet drafts" - "Withdrawals in progress" - "Changes waiting for approval" A kind it could not check reads "``: could not check". Select **Switch off** to confirm or "Keep on" to leave the module on. After a save the row reads "Modules saved". ## Choose the languages [#choose-the-languages] The "Language and time zone" section holds the **Languages** row and, below it, the "Display time zone" row. In the "Languages" row, an organisation owner chooses which of the ten languages people in the organisation can pick, and [Languages](https://docs.settlemint.com/docs/console/organisation-settings/languages) covers that row. ## Set the display time zone [#set-the-display-time-zone] The investor portal shows every time, chart axis, statement date and deadline in the display time zone, with its short name, whatever time zone the investor's browser uses. An investor in Brussels and an investor in Dubai then read the same trade at the same clock time, and that time matches the instrument's own trading day. For Asia/Dubai the portal writes `GST`, short for Gulf Standard Time. The **Display time zone** row shows the zone in use and where it comes from: - **Set for your organisation.** An owner chose a zone from the searchable list. "Search time zones" filters it, and the list reads "No time zone matches." when nothing fits. - **Follows the venue calendar.** No zone is stored, and every trading venue calendar of the organisation uses the same zone. - **No venue calendar zone applies, so times show in UTC.** No zone is stored, and the venue calendars set no zone or set different ones. Choose **Use the venue calendar zone** to clear a stored zone. A save toasts "Display time zone saved". The Console itself keeps showing UTC. ## Publish trading terms and risk disclosures [#publish-trading-terms-and-risk-disclosures] The "Terms and risk disclosures" row, in the "Terms and disclosures" section, publishes the documents that participants must accept before they can trade or withdraw. Choose "Terms" or "Risk disclosure", enter a numeric version and either the document text or a file reference, then select **Publish**. Set **Require participants to accept this version again** when an update should prompt every participant. Without it, an acceptance of an earlier version with the same major number still counts. The Console publishes a version that takes effect at once. Through the API, a future effective date keeps the version out of the gate until that date. The row counts published versions and recorded acceptances. **Export acceptances** downloads the participant, document, version, time, and request metadata as CSV. The Investor portal shows the current effective versions after sign-in and opens the rest of the portal only after the participant accepts each one. ## Show redemption funding to holders [#show-redemption-funding-to-holders] The "Terms and disclosures" section also holds the **Redemption funding** row. Its switch is named by the text beside it: "Hidden from holders" until you turn it on, and "Shown to holders" afterwards, so a screen reader announces the same words a sighted reader sees. It controls what a holder sees when they redeem a matured bond, and whether a refused yield claim names the yield treasury and the amount owed. A link on a bond's maturity tab opens this row. - **Off:** the holder's redeem sheet shows no treasury figure and no shortfall notice. The role holders this section names still see the figures. If the treasury cannot pay, the redemption is refused with "This redemption cannot be completed", and a yield claim the treasury cannot pay is refused with "The yield treasury cannot pay this claim yet", without the treasury or the amount owed. - **On:** the holder's redeem sheet, in the Console and in the investor portal, shows the treasury's available balance in the denomination asset. When the requested payout is more than that balance, the sheet shows the shortfall and blocks the redemption. A redemption or yield claim the treasury cannot pay is refused with an error that names the treasury and the amounts. The redeem sheet reads the switch each time it opens. A change applies the next time a holder opens the sheet, with no page reload, and the sheet hides the treasury figure until that read settles. An account that holds a management role on the asset always sees the treasury figures, whatever the switch says: custodian, emergency, funds manager, governance, sale admin or supply management. So does an account with the "Permission manager", "Auditor", "System manager" or "Token manager" role on the system, and the bond's maturity treasury wallet. Only an organisation owner can change the switch in the Console. ## Set idle sign-out [#set-idle-sign-out] The "Security" section opens with the **Idle sign-out** row. It signs a person out after the chosen time without activity. In the Investor portal, that means no mouse, keyboard or page-visibility activity. Everywhere, it also means no request has reached the platform for that long. The choices are "Off", 15 minutes, 30 minutes, 1 hour, 2 hours or 4 hours. "Off" is the default and keeps people signed in until their session ends. A choice saves at once and the row reads "Idle sign-out setting saved". The row lists a stored value outside its choices as an extra choice. ## Set the cooling-off period [#set-the-cooling-off-period] The "Security" section holds the **Cooling-off after a wallet security change** row, after "Idle sign-out". These changes to a member's wallet signing factors count as a wallet security change: - a transaction PIN set, changed, removed or reset - a transaction code added or removed - recovery codes regenerated After one, DALP emails the member what changed, when and from where, and refuses every transaction that needs their wallet verification, the PIN, transaction code or recovery code that confirms a transaction, for the period this row sets. The row shows the period in hours when it divides evenly, "24 hours" by default, and "Off" at `0`. A whole number of minutes from 0 to 10080, which is seven days, is accepted, and anything else reads "Enter a whole number from 0 to 10080." Setting it to `0` turns the hold off. The security email is always sent. Select **Save** to store a new period, which toasts "Cooling-off period saved". The hold starts when a change alters or removes a factor the member already held, adds a second one, or replaces a confirmed set of recovery codes, and when an identity manager resets the member's PIN, so a new member who sets up their first PIN and recovery codes is not held. A member who sets a factor up again after an identity manager reset their PIN is held again from that setup. While it stands, every signing request the member sends is refused with the instant the hold ends, in the Console and in the investor portal alike, and the same instant is in the email. A member of several organisations is held for the longest period any of them sets, so switching organisation never shortens the hold. A later security change restarts the period from that change. Only an organisation owner can change the row in the Console. Anyone else who opens the page sees the value without a control. Making the period longer saves at once. Making it shorter, or turning it off, weakens the hold for every member, so the Console opens **Shorten the cooling-off period** and asks for your wallet verification first. While you hold a transaction code, the platform accepts only that code and refuses a PIN or recovery code without saving. The save is refused while your own hold stands. Members who are held at that moment are not a reason to refuse: their hold end is recomputed under the new period, and each of them whose hold end moves gets one email with the period that now applies to them and the new hold end, or that the hold has ended. A longer period can also bring back a hold that had already ended. That member gets the same email. No other member is emailed about the change. An API key cannot shorten the period. When a member's hold runs out, DALP emails them that their signing hold has ended, once per hold, within about five minutes. If the email cannot be sent, DALP tries again five minutes later. A hold that runs out on its own while the period is **Off** ends without this email. ## Segregation of duties [#segregation-of-duties] The **Segregation of duties** section sets which pairs of on-chain roles one wallet may not hold together, and what happens to a grant that would put a pair on one wallet. The "Check role grants" row holds the switch. It reads "Role grants are not checked" or "Role grants are checked against the rules". The switch starts off, so no grant is compared with the rules until an owner turns it on. Roles already granted stay as they are, and the conflict report lists the pairs held today whether the switch is on or off. Below the switch, a table lists the rules with the columns **Roles**, "Applies" and "When broken". An organisation that never saved the setting sees the default pairs, each set to refuse the grant. The first change you save stores the whole rule set, so the defaults you leave in place stay in it. - **Applies** reads "On the same contract" or "Anywhere in the organisation". A same-contract rule breaks only when both roles sit on the same token, token sale or venue. An organisation-wide rule breaks wherever the wallet holds the two roles in the organisation's system. - **When broken** reads "Refuse the grant" or "Ask for a reason". A grant that breaks a refusing rule is turned away. A grant that breaks a rule that asks for a reason goes ahead only with a reason, which the audit trail keeps. To change the rules, turn the switch on or off, choose another value in **When broken** on a row, or open a row's menu and choose "Remove rule". To add a rule, go to "Add a rule" under the table, choose the "First role" and the "Second role", set "Applies" and "When broken", and choose "Add rule". A pair takes one rule for each place it applies. "Choose two different roles." and "This pair already has a rule in that scope." tell you why a rule is not added. Each change saves at once and toasts "Segregation of duties saved". Only an owner can change the rules in the Console. Anyone else who opens the page sees the rules without a switch, a menu or **Add a rule**. The Console's role editors send no reason. A grant that breaks a rule that asks for a reason is therefore turned away there, with the line "The organisation allows this grant with a reason. Send it through the Platform API." The alert above the buttons names each pair that conflicts, such as "Custodian cannot be held with Governance on the same contract." [Roles and permissions](https://docs.settlemint.com/docs/console/organisation-settings/admins-and-roles) shows where the editor shows it, and the [Roles and segregation of duties reference](https://docs.settlemint.com/docs/concepts/compliance-and-identity/roles-and-segregation-of-duties) lists the roles and the default pairs. ## Approvals [#approvals] The **Approvals** section chooses which changes wait for a second person. It lists ten families: Offerings, Corporate actions, Trading venues, Reporting, Bank rail, Custody operations, Withdrawals, Prices, Wallets and Administration. Each row reads "Second person required" or "Not required" and has a "Turn on" or "Turn off" button. Its screen-reader label names the family, such as "Turn off approval for offerings". The Reporting row and its obligation exceptions read the same way, although the row also controls publishing an obligation, which never waits for a second person. The row's description says what waits while the family is on, or what goes ahead while it is off. A save toasts "Approval rule saved". The person who makes a change never approves it. A different person who may approve that kind of change decides it on the **Actions** page. - **Offerings:** creating an offering, opening it for sale, ending it and running the allocation of an oversubscribed offering wait for a second person. The approver sees the sale terms before deciding: the token, the caps, the purchase limits, the start, the duration, the network, the payment currencies with their price per token, the country by name, the presale discount as a percentage and the terms fingerprint. - **Corporate actions:** recording a corporate action waits for a second person. - **Trading venues, Reporting and Administration:** the row sets the organisation-wide choice. A venue, a reporting obligation or an Administration protection group that has its own choice appears under "Exceptions": a venue by its name and network, an obligation by its name, a group by its label. Each exception has its own "Turn on" or "Turn off" button and a "Remove" button that returns it to the family's choice. To add one, pick from the list under the row ("Choose a venue", "Choose an obligation" or "Choose a protection group"), then select "Require approval for this one" when the family is off, or "Turn off approval for this one" when it is on. Until you pick, the button stays disabled and the row says why, for example "Choose a venue to add an exception." The list offers the venues on the network the Console is set to, and the first 100 obligations. - **Reporting:** while it is on, releasing a venue legal hold waits for a second person, and the platform publishes a reporting obligation only while the organisation has at least two members with the Owner role. Otherwise publishing is refused with `DALP-0719`. An obligation exception changes only that obligation's publishing check, with "Turn on the check for this one" and "Turn off the check for this one". - **Bank rail:** the row decides whether these changes wait for a different Bank rail manager: a cash-out over the checker threshold, a credit over the credit threshold, the allocation or return of a parked credit, a reserve adjustment, a raised or removed credit threshold or mint cap and the completion or abandoning of a rail wallet rotation. Three controls wait for a different manager whatever the row says: approving a client's bank account, executing or abandoning a recall, and the re-credit of a returned payout. The "Approvals required" count applies to the family's changes only. When it is above 1, only an organisation owner who also holds the Bank rail manager role can decide them. [Bank rail](https://docs.settlemint.com/docs/console/asset-lifecycle/bank-rail#before-you-start) lists the changes from the manager's side. - **Custody operations:** resolving a reconciliation break waits for a second person. [Custody reconciliation](https://docs.settlemint.com/docs/console/organisation-settings/custody-reconciliation) shows it from the reconciler's side. - **Withdrawals:** the row remains but governs nothing. Withdrawal approvals are retired, so withdrawals go ahead without a second person. - **Prices:** a held price from a price source waits for a second person before it is used. [Price sources](https://docs.settlemint.com/docs/console/organisation-settings/price-sources#held-prices-and-the-second-approver) explains the hold. - **Wallets:** the row decides whether pushing a wallet's entitlements waits for a second person. A wallet approval that names its checker always waits for that person, whatever the row says. Under the state of each family that is on, except Reporting, **Approvals required** sets how many different people must approve before a change in the family goes ahead. It starts at 1 and goes up to 10. The person who made the change never counts. The count you set here applies to every kind of change in the family, and a venue or protection group follows it. Through the API an owner can also give one kind of change its own count, approver roles and expiry, and give a venue or protection group its own count. The row then shows the highest count among the family's kinds. The Reporting row has no count, because nothing in Reporting would read one: one different person decides a legal hold release, and publishing an obligation needs two members with the Owner role. A change that is already waiting keeps the count it started under. Approver roles set on administrative changes never apply to a change of these approval rules: another owner or a platform administrator still approves that. Raising the count saves at once. Lowering it weakens a control, so the Console opens "Ask for fewer approvals for ``?" and asks for your wallet verification, as "Turn off" does. Select **Lower the count** to continue or "Keep the current count" to cancel. While any Administration protection group is protected, the lower count then waits for another owner or platform administrator to approve it. "Actions" shows a change that needs several approvers with its progress, for example `1 of 2`. If you ask for more approvers than the organisation has people who may approve the change, it cannot be completed and lapses. "Turn on" saves at once. **Turn off** weakens a control, so it opens "Turn off second-person approval for ``?" and asks you to confirm with your wallet verification. "Turn off approval" sends the change and "Keep approval on" cancels it. A similar confirmation, which also asks for your wallet verification, guards every other change that removes a second-person check: turning an exception off, adding an exception that turns approval off, and, while the family is off, removing an exception that required approval ("Remove the exception for ``?", with "Remove exception" and "Keep exception"). An obligation exception removes no second-person check, so its confirmation reads "Allow publishing `` with fewer than two owners?" instead, with "Allow publishing" and "Keep the check". The change then applies at once. While any Administration protection group is protected, the change waits for approval instead: the row keeps its current state and reads "Turn-off waiting for approval" until another owner or a platform administrator decides. That approver can be a platform administrator, so no owner of the organisation is necessarily asked. The row says who asked, when, and when the request lapses, in UTC: it names the member who asked, or reads "someone else" when the name is not known. On a turn-off you asked for yourself, the row offers **Withdraw request** in place of "Turn off". It cancels the request at once, with no PIN: the family keeps asking for approval, and the request leaves Actions so nobody can approve it. Only the member who asked can withdraw it. Another owner approves or rejects it instead. A request already waiting keeps the rule it started under. A request raised while its family is off runs without a second person. **Actions** and its detail sheet show it as "No second approval (approval off)". While any Administration protection group is protected, every edit of the list of protection groups and every change that switches a family or exception off or lowers a count waits for an owner or platform administrator to approve it, whatever the number of owners. Turning a family on and raising a count apply at once, with no PIN. A session in which a platform administrator acts as another user cannot switch an approval off, lower a count or remove an exception. Sign in as yourself to do it. ## You should see [#you-should-see] - A name or logo save confirms with a toast: "Updated successfully", "Logo uploaded", "Logo removed" or "Logo restored". - The modules, idle sign-out and redemption funding rows confirm in the row itself, such as "Saved". - Display time zone, cooling-off and approval saves confirm with the toasts each task names. - The new name or logo is already visible on General itself and everywhere else that reads the organisation directly, no reload needed. - If your account belongs to more than one organisation, the **Organisation** submenu of the account menu can lag behind: it reads a separate list that refreshes only on a full page reload, or once idle five minutes when you switch back to the tab. - In-app navigation between Console pages does not trigger that refresh. ## Troubleshooting [#troubleshooting] **The “Edit”, “Upload” and “Remove” buttons are missing** The controls show only to an owner of the organisation. A platform administrator who is not an owner sees the values and one line saying that organisation owners manage these settings. Ask an organisation owner to make the change, or to make you an owner. A member who is neither sees no **General** in the sidebar, and a General link opens the Not available page. **The new logo or name is not visible elsewhere** If General itself still shows the old name or logo, the save did not go through. Check for "Request failed" under the name field or in a toast rather than reloading, since General already reflects a successful save without one. The Organisation submenu, for an account in more than one organisation, is different: it can lag by design, so give it a full reload before treating it as a bug. **The logo upload is rejected** The Console checks the file in a fixed order: an empty file fails first, then an unrecognised image type, then a mismatch between the file's declared type and its actual contents, then anything over 500 KB. A renamed file extension does not get past the content check, so if the upload fails, confirm the file is an SVG, PNG, JPEG, or WebP under 500 KB and not a different file renamed to look like one. **Save fails with “Request failed”** A name save shows "Request failed" under the name field, and a logo save shows it in a toast. The server rejected the request after the Console already let you submit it. This can happen if your role's permission changed since the page loaded, or from a temporary network problem. The message includes a reference id. If retrying does not clear it, share that id with your platform administrator. ## Frequently asked questions [#frequently-asked-questions] ### Does renaming the organisation change its slug? No. Name and slug are separate fields on the organisation record, and the Profile section only ever sends the field you changed: a name edit sends the name, a logo change sends the logo. Nothing in this workflow reads or writes the slug, so anything keyed on the slug stays as it was. ### What happens if two people edit the profile at the same time? The last save wins. The update request carries no version check, so if a colleague saves a name change moments after you save a logo change, both land, because they touch different fields. Two people changing the same field in the same window is different: whichever save reaches the server second overwrites the first, with no conflict warning to either person. ### Does an API key need the Owner role to change the General settings? For the name and logo, yes: the request must come from an owner of the organisation, whether it uses a session or a supported API key. The settings rows written through `/api/v2/settings` and the approval rules also accept a platform administrator. Scope bounds which kind of request a key may make. It does not widen what its underlying account may do at the organisation level. Create the key under an owner's account, or have an owner create it for your integration. ### Does this page change my own name or login details? No. Your account menu has its own page called Profile, which holds your email, password and identity details. General changes only organisation-wide settings, and its Profile section changes only the organisation's name and logo. An account can belong to more than one organisation, and each keeps its own name and logo here, independent of every other one that account can switch into. ## API routes [#api-routes] - The `IDLE_TIMEOUT_MINUTES` setting behind **Idle sign-out** is written through `POST /api/v2/settings`, which accepts `off` or a whole number of minutes from 5 to 240. - The `SIGNING_FACTOR_COOLDOWN_MINUTES` setting behind the cooling-off row is written through `POST /api/v2/settings`. A value below the current one needs `walletVerification` in the body. Deleting the setting, which returns it to the default, is refused while the current period is longer than the default. Set it to `1440` with `walletVerification` instead. Both checks run again against the value stored at the moment of the write, so a save that another administrator's longer period, saved just before it, turns into a shortening is refused with `403`. Verify and save again. A held signing request answers `403 WALLET_VERIFICATION_HELD` with `heldUntil` and `retryAfterSeconds` in its data. - The approval rules are `GET /api/v2/operations/approval-policy` and `PUT /api/v2/operations/approval-policy`, where each family carries `requiredApprovals` and, under `kinds`, each kind of change its own `enabled`, `requiredApprovals`, `approverRoles` and `expiryHours`. A `PUT` with `kind` sets only that kind. A `PUT` that weakens a rule needs `walletVerification`: turning a kind off, lowering its count, adding an approver role, making its expiry longer, or setting roles or an expiry where the kind used the action's own. A `PUT` that is held answers `202` with the approval id. The setting `CORPORATE_ACTION_MAKER_CHECKER_ENABLED` reads and writes the **Corporate actions** row. - The display time zone is readable with `GET /api/v2/settings/display-time-zone`, which answers the zone and its source. - The redemption funding switch controls the v2 reads `GET /api/v2/tokens/{assetId}/stats?metric=bondStatus` and `GET /api/v2/tokens/{assetId}/treasury/health`. While it is off, any other caller gets a 403 `TREASURY_DISCLOSURE_WITHHELD` answer from both. The frozen v1 read `GET /v1/token/{tokenAddress}/stats/bond-status` is outside the switch: any member of the organisation can still read it.