workflow, read both the old-value and the new-value for a given It

All --

Please help.

I am making some custom workflows with SharePoint Designer.

I need to be able to, in a workflow, read both the old-value and the
new-value for a given Item field.

Right now, all I can find is CurrentItem.FieldName for switching logic--
but, there is no descriminator so that I can get the "value before the
change" and the "value after the change".

How can this be done?

Part of the issue is that I need to send email as follows...

...start the workflow automatically when the document is created and when
the document is changed, and in the workflow run logic something like the
following...

If ((OldStatus DoesNotEqual ReadyForReview) And (NewStatus DoesEqual
ReadyForReview)) Then
Do send the email.
Else
Do not send the email.
EndIf

...the problem is, as you can see, that I need access to the old-value and
the new-value.

I am sure this can be done some way; but, I am new to workflows so I do not
yet know how.

Please advise.

Thank you.

-- Mark Kamoski
--
http://www.WebLogicArts.com

Hello mkamoski,Could you grab the old status when the workflow kicks off and

Hello mkamoski,

Could you grab the old status when the workflow kicks off and store it in
a variable (or in a hidden field on the item)?  It will then be available
when you kick off the workflow.

Another choice, if all you're doing is sending the email, would be to look
into Event Handlers instead of workflow.  I believe you can get to both before
and after values then.

Dave

workflow, read both the old-value and the new-value for a give

I tried this. In theory, it should work. However, in practice, there is a
detail that I cannot solve, which is a problem.

Maybe you can help with this further?

The problem was that I do not know how to make a custom column on a Document
Library list completely "hidden" from the enduser.

I can hide the column from every view; but, when one checks-out a document
and then opens it for editing in Word 2003 or Word 2007, then the Office
integration automatically shows the custom column in the Word interface.
Therefore, since the enduser can see the custom column, then the enduser
could potentially change the value, which would not be allowable for my
purposes because the field's would need to completed hidden from the enduser,
(or at least completely read-only).

In this case, the question becomes-- how can one add a read-only custom
column to a Document Library list?

Please advise.

Thank you.

-- Mark Kamoski

workflow, read both the old-value and the new-value for a give

You are right.

Using an EventHandler is a good idea. Both the BeforeProperties and
AfterProperties are available in some events.

Unfortunately, for me, I must use a Workflow for this.

If other ideas exist, then please post them.

Thank you.

-- Mark Kamoski

You can hide or make a field readonly by changing the list schema, or you can

You can hide or make a field readonly by changing the list schema, or you can
download the sharepoint tips utility pack which allows you to hide fields or
make them read only by code:
http://sps.uniqueworld.net/Canberra/Free%20Downloads/1/SharePoint_Tips_Utility_Pack.zip

Ishai Sagi
www.spstips.blogspot.com

workflow, read both the old-value and the new-value for a give

How can one change the list schema?

Would one use SharePoint Designer or something else?

Can you provide a hint on how to approach this?

Please advise.

Thank you.

-- Mark Kamoski

A list schema is defined in xml in the site definition for the site you are

A list schema is defined in xml in the site definition for the site you are
using. I have no links available now, but if I get some free time today I
will post some. I suggest you look into site definitions and CAML schemas in
google.

Ishai Sagi

workflow, read both the old-value and the new-value for a give

Regarding the issue of how to make a field read-only, that is nicely solved
by your excellent SharePoint Utility tool, that you link in a post above in
this thread,
http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.sharepoint.development_and_programming&mid=cb6101ae-360f-4f10-8f00-b2cd34ec7321&sloc=en-us . so I really appreciate that nice tool.

Regarding the site definitions and CAML, I think that I see the direction
required there and I appreciate direction.

However (and unfortunately) I am still stuck.

Why?

Well, with the help of the SharePoint Utility Tool that you provided, it is
truly simple to set a field as read-only. Unfortunately, doing so apparently
writes to the Site Definition and/or CAML for the given List and that is,
apparently, the same location that the SharePoint Designer Workflow Builder
reads-- therefore, setting the field to read-only makes it read-only to
SharePoint Designer Workflows too. That is not what I need. What I need is
the field to be read-only to the enduser (so that he/she can in no way ever
change it) and at the same time making the field read-write to the SharePoint
Designer Workflow Builder.

The quest goes on.

It is proving to be very limiting that the SharePoint Designer Workflow
Builder does not provide access to both the old-value data and the new-value
data of the List item. I want to do something pretty basic-- if
OldStatus=SomethingOtherThanReadyForReview and NewStatus=ReadyForReview then
SendEmail. That's pretty tricky because I do not know what the OldStatus is.

It is beginning to look like I must use an EventHandler for this, which I
find to be VERY odd. The SharePoint Designer Workflow creator is really nice
but it seems to be missing a few things to make it great and really useful,
IMHO. Maybe (and I hope) this is just due to my lack of knowledge-- but, no
one seems to have an answer to this this anywhere.

If anyone has any more thoughts, please send them along.

Thank you.

-- Mark Kamoski

Using my tool you can instead hide the field from the "new" and "edit" forms,

Using my tool you can instead hide the field from the "new" and "edit" forms,
so the user can only "view" the field in the view form.

Ishai Sagi

workflow, read both the old-value and the new-value for a give

Yes. I see that now. That is great. It really is. You really might want to
promote your tool a bit. I will do it as much as I can. I am sure that it can
answer a lot of questions for a lot of people. FYI, this newsgroup
http://www.SharePointU.com is also pretty well travelled.

Now, I have another issue. I can now persist the old-value and new-value for
a given field in a given List by using a hidden field for the old-value. That
is fine. Unfortunately, to update the old-value as needed, the item needs to
be checked out. And, it seems, a checkout causes my Workflow to trigger
again, because it is set to start whenever an item changes. Therefore, my
Workflow runs 2x. Ug. Not good. I may have to use an Event Handler after all,
unless I find a better way.

Back to the drawing board. The problem that I am trying to solve is as
follows.

When a new item is created and whenever an existing item is changed in any
way, run the following simple logic...

Start the Workflow.

If ((OldStatus DoesNotEqual ReadyForReview) And (NewStatus DoesEqual
ReadyForReview)) Then

Send an email to A and B.

Else

Do nothing.

End If

Stop the Workflow.

In plain English, we have: If the Status changes from
SomethingOtherThanReadyForReview to ReadyForReview, then send an email;
otherwise, do nothing. There should be email sent only when the Status
changes to ReadyForReview. Unfortunately, the business processing is
non-linear; for example, it could go as: Status=NotSet, Status=Draft,
Status=ReadyForReview, Status=ReadyForPublish, Status=Draft,
Status=ReadyForPublish, Status=ReadyForReview, and so on. It can go from any
state to any state at any time.

If you, or anyone, has any hints on how to solve this, then please let me
know.

Thank you.

-- Mark Kamoski

check my blog, I once wrote a sample on how to do administrative update for an

check my blog, I once wrote a sample on how to do administrative update for
an item to prevent recursive event trapping. I am not sure if that will solve
the workflow issue as well, but you might as well try,
--
Ishai Sagi
www.spstips.blogspot.com
Developer tips for SharePoint