For stewards

Requests and approvals

Changes that need somebody's agreement, and how to decide them.

What a request is

A workflow is a set of rules for one or more kinds of asset, such as Business Terms, or Data Entities and Data Products together. It says which changes need a decision, who makes it and in what order. When a published workflow governs an asset, editing it on its page doesn't save anything. Each edit goes into your change set for that asset: a changed value, the name or key, a link added or removed, or someone given or taken off a responsibility. When the set holds everything you mean to change, you submit it as one change request. The asset stays as it was until the request is approved, and then everything in it is applied together.

The asset page tells you this before you start: Changes here are proposed, not written.

Build and submit a change set

Open the asset and edit it as usual: click a value, add or remove a link, give or take away a responsibility. Each edit appears under Your change set, and nothing on the asset changes.
Editing the same thing twice keeps only the last edit. Press × beside an edit to take it out.
Type What this is, in a line (the request's title) and, if you like, Why for whoever decides.
Press Submit … for approval. You land on the new request.

Your change set is kept until you submit or discard it, even if you sign out. Change requests lists Your drafts at the top. Only you see your drafts. Discard throws a draft away.

Links between two governed assets

A link joins two assets. If the asset at the other end is also governed, its workflow must approve the link too. Submitting raises a second, paired request on the other asset. The link is made only when both requests are approved. Until then the first approval shows the link as waiting, with a link to the other end's request. If either request is turned down, the link isn't made. If only the other end is governed, adding the link from the ungoverned side raises a request there.

A new asset

Creating an asset of a governed type makes a proposed asset rather than a real one. It opens on its own page, headed A proposed …. It isn't on any list, in any search or in any count. Only you, whoever decides on it and administrators can open it. Add values or links to it, then press Submit for approval. When the request is approved, the asset becomes an ordinary one. If it's turned down, it stays hidden with its request as the record, and its key is freed so it can be proposed again. Discard before submitting removes it.

A workflow can also start in other ways, depending on how it was set up:

when an asset of that type is created (to certify it, for example)
when something changes, which can be a characteristic, a link, or who is responsible. The change has already happened, and the request records that somebody looked at it.
when somebody asks to delete an asset. The deletion waits until someone approves it.

Before you start

To propose a change you need to be able to edit the asset, and you need Propose changes (WORKFLOW_RAISE). In the starter model both come with Data Owner and Data Steward.
Who may approve or reject is set on each step of the workflow. It is either a role held over the asset (such as the Data Owner of its domain) or a permission held over the whole repository.

Find what's waiting on you

Open Change requests in the sidebar, under Governance.
Waiting on your name lists the requests you can act on now. Everything else open lists the rest.

Each row shows what the request is about, the asset, its current state, when it is due, how many changes it holds, who raised it, and which steps you can take. A request past its time is marked overdue. Messages a workflow has sent you appear at the top. Press Mark as read to clear them.

"Waiting on you" is worked out whenever you open the screen, from the roles you hold at that moment. If your responsibilities change, the list changes with them.

Times are in your own zone

Every time KRISID shows you — a deadline on Change requests, the Due line on a request — is written in the zone your browser is in, and labelled with it: Wed, 23 Sep, 21:30 GMT+5:30. Hover it and the zone is named in full. Nobody sets this; your browser says where it is when you sign in.

Emails follow the same rule. A deadline in an email is written in the zone the person reading it last signed in from, so the same task can reach Mumbai as 21:30 and New York as 12:00. It is one moment either way — the spelling changes, the deadline does not, and nothing that is counted (overdue, reminders, working days) is affected.

The zone your browser reported is shown on People and Persona beside your name, and on your own page. It is a fact, not a setting: you can't type it, and it changes by itself when you sign in from somewhere else.

Decide a request

Open the request from Change requests.
Read What would change. For each field it shows It said (the value when the request was raised), It would say (the proposed value) and Since then.
Under What you can do, find the step you want. In the standard templates the steps are Approve and Reject; a certification workflow uses Certify and Send back.
Type a note in the box beside it. If the box says why — required, you must give a reason.
Press the step's button.

The request moves to its next state, and What has happened records who did what, when, and why. When a request reaches its final approved state, the change is applied to the asset and appears in the asset's History as an ordinary edit, recorded against the person who approved it.

If a step is listed but you can't take it, the reason is shown beside it. A common one: the workflow says the person who raised the request can't also approve it.

When every approver must answer

Some states ask every one of the people who hold a role, not just any one of them. The request page then shows Waiting at with the people asked, what each has answered so far, and when it is due. The people asked are fixed when the request arrives, so someone given the role later isn't added.

When you answer, your answer is recorded and the request waits for the others. You can answer only once.
Under Every one of them — one other answer decides, the request moves when everyone has approved, or at once when any one of them rejects or sends it back.
Under Every one of them — wait for every answer, the request moves only when everyone has answered. If all approved, it is approved. If not, it takes the first other answer given.

Important: If a value has changed since the request was raised, Since then says changed since and approving is refused. KRISID won't overwrite a value nobody agreed to replace. Reject the request and propose the change again against the current value.

What the workflow did

When a workflow tells somebody, sends an email, sets a value or calls another system, the request lists it under What the workflow did, with whether each action worked. If an email or a call to another system failed, press Try again. An email that says no email address for someone can be sent once they have an address: add it under People, then press Try again.

Emails go out through the mail server set on Administration → Email (see Sign-up and the mail server). If none is set, the email is listed as failed with the reason, and the request itself carries on.

The Workflows screen

Workflows are drawn and published on their own screen, and that has a page of its own: Designing a workflow. It covers the canvas, a workflow's scope, condition boxes, who is asked and by when, reminders, and what happens when time runs out.

Good to know

One change set, one request, however many edits it holds. A stale value still stops approval: if a value has changed since the request was raised, approving is refused.
A direct write through the API, and a load from Excel, follow the Workflow controls set on People and Persona. By default both write directly, as before. See People, roles and access.
Reminders and time limits are set per state. A state without them waits for as long as it takes, so check Change requests regularly.